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 не змушує цю опцію налаштовувати його.

Схожі статті