Utiliser un proxy pour un seul dépôt Git

Vous n’avez pas besoin d’un proxy Git global simplement parce qu’un projet nécessite une autre connexion. Une copie de travail existante possède sa configuration locale : le changement peut rester limité à ce dépôt.

Ces exemples utilisent les commandes actuelles git config set/get/unset. Le répertoire du projet, l’URL distante et l’IP de documentation sont des valeurs de remplacement. Pour tester un dépôt public où les proxys publics sont autorisés, choisissez un candidat dans la liste de proxys HTTP.

git -C project config set --local http.proxy http://203.0.113.10:8080
git -C project ls-remote origin

L’URL du proxy inclut son schéma de transport. Un distant HTTPS peut utiliser un proxy HTTP ordinaire compatible CONNECT ; le schéma HTTPS du distant n’impose pas de passer l’URL du proxy en HTTPS.

Vérifiez ce que Git a réellement choisi

Si le résultat est inattendu, examinez la valeur choisie pour l’URL distante réelle :

git -C project config get --show-origin \
  --url=https://example.com/team/project.git http.proxy

Utilisez votre véritable distant HTTPS dans cette requête. Git peut avoir des réglages système, utilisateur, dépôt, ligne de commande et spécifiques à une URL. Consulter uniquement une valeur globale http.proxy peut faire manquer une règle plus précise. L’affichage de l’origine aide à identifier le fichier ou la source en ligne de commande du résultat.

Le réglage local s’applique aux accès HTTP depuis ce dépôt, pas seulement à une branche. Un dépôt avec plusieurs distants HTTP peut donc l’utiliser pour d’autres que celui testé en premier. Des réglages HTTP propres à une URL existent pour un ciblage plus étroit.

Avant que la copie de travail existe

Pour le clonage initial, décidez si la surcharge doit persister ; pour la limiter à cette invocation de Git, utilisez :

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

La surcharge en ligne de commande ne devient pas d’elle-même une entrée de configuration permanente dans la nouvelle copie. Définissez ensuite une valeur locale si les futurs fetch doivent emprunter ce trajet.

Un distant SSH est un autre cas

Un distant commençant par git@host: ou ssh:// utilise SSH. Le réglage proxy HTTP de Git ne le transforme pas en transfert HTTP. Vérifiez le transport du distant avant de remplacer une IP de proxy fonctionnelle simplement parce qu’une opération SSH échoue encore.

Quand la surcharge locale n’est plus souhaitée, retirez uniquement cette clé :

git -C project config unset --local http.proxy

Sa suppression laisse de nouveau s’appliquer les configurations pertinentes d’autres sources. Cette commande n’efface pas tous les réglages proxy de la machine.