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 не заставляет эту опцию настраивать его.

Похожие статьи