Git Clone: задайте прокси преди първия fetch

Използвайте конфигурация при клониране, когато ново хранилище се нуждае от собствен прокси от първата мрежова заявка.

Прокси, локално за хранилището, звучи неудобно, преди хранилището да съществува. Не е нужно да клонирате неуспешно, да редактирате конфигурацията и да започвате отначало.

Clone може да запише локална настройка преди първия fetch:

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

Тези крайни точки са примери. За публично HTTPS хранилище по разрешен маршрут на публичен прокси изберете HTTP крайна точка от списъка с HTTP прокси. Git документира тази опция като действаща след инициализиране на новото хранилище и преди извличане на отдалечената история. За тази настройка на прокси тя може да покрие първото изтегляне и да остане в новото хранилище.

Две подобни команди оставят различни следи

За да дадете маршрута на едно извикване, без да съхранявате настройката в клонираното хранилище, поставете -c преди подкомандата:

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

git clone --config ... и git -c ... clone не са взаимозаменяеми обхвати на конфигурация. Изберете дали бъдещи операции в това хранилище трябва да запазят проксито.

Проверете локалната конфигурация на новото хранилище, когато този избор е важен. Други потребителски, системни или URL-специфични настройки също могат да участват в ефективната политика.

Пазете паролите извън тези примери, когато съхранявате маршрута. Стойност с идентификационни данни, подадена на конфигурационната опция на clone, може да стане постоянна настройка на хранилището.

Това е конфигурация на HTTP транспорта, включително HTTPS отдалечени хранилища. SSH хранилището все още се нуждае от своя SSH прокси маршрут; преместването на SSH на порт 443 не кара тази опция да го конфигурира.

Подобни статии