Depo var olmadan önce depoya özel bir proxy garip görünür. Başarısız clone yapıp yapılandırmayı düzenlemeniz ve baştan başlamanız gerekmez.

Clone ilk fetch'ten önce yerel bir ayar yazabilir:

git clone --config http.proxy=http://proxy.example.net:8080 \
  https://git.example.net/team/project.git project

Bu uç noktalar örnektir. İzin verilen genel proxy rotasındaki genel bir HTTPS deposu için HTTP proxy listesinden bir HTTP uç noktası seçin. Git, bu seçeneğin yeni depo başlatıldıktan sonra ve uzak geçmişi fetch edilmeden önce geçerli olduğunu belgeler. Bu nedenle bu proxy ayarı ilk indirmeyi kapsayabilir ve sonrasında yeni depoda kalabilir.

İki benzer komut farklı izler bırakır

Rotayı, ayarı klonlanan depoda saklamadan tek bir çağrıya vermek için alt komuttan önce -c koyun:

git -c http.proxy=http://proxy.example.net:8080 \
  clone https://git.example.net/team/project.git project

git clone --config ... ve git -c ... clone birbirinin yerine geçebilen yapılandırma kapsamları değildir. O depodaki gelecekteki işlemlerin proxy'yi koruyup korumayacağını seçin.

Bu seçim önemli olduğunda yeni deponun yerel yapılandırmasını inceleyin. Diğer kullanıcı, sistem veya URL'ye özgü ayarlar hâlâ etkili politikaya katılabilir.

Rotayı saklarken parolaları bu örneklerin dışında tutun. Clone'un yapılandırma seçeneğine verilen kimlik bilgisi içeren bir değer kalıcı bir depo ayarına dönüşebilir.

Bu, HTTPS uzak depoları dahil bir HTTP taşıma yapılandırmasıdır. Bir SSH uzak deposu yine de kendi SSH proxy rotasına ihtiyaç duyar; SSH'ı 443 bağlantı noktasına taşımak bu seçeneğin onu yapılandırmasını sağlamaz.

İlgili makaleler