Donnez à Git des règles de proxy différentes selon les hôtes
La configuration HTTP propre à une URL de Git peut garder un service interne en direct tout en conservant un proxy ailleurs. Inspectez le résultat de correspondance pour l'URL exacte.
Une seule configuration Git peut desservir deux itinéraires très différents : un hôte externe atteint via un proxy approuvé et un hôte interne atteint directement. Vous n'avez pas à modifier la valeur globale par défaut à chaque changement de dépôt.
Git prend en charge une configuration HTTP propre à une URL. Par exemple :
[http]
proxy = http://proxy.example:8080
[http "https://git.office.example/"]
proxy =
Pour un dépôt public externe où les proxys publics sont autorisés, la liste de proxys HTTP propose des candidats pour le point de terminaison par défaut. La valeur vide est une substitution explicite pour l'URL correspondante. Elle diffère de la suppression de cette clé plus spécifique, qui peut réexposer le proxy générique.
Faites correspondre l'URL utilisée par Git
Le schéma, le nom d'hôte, le port, le chemin et le nom d'utilisateur facultatif participent aux règles de correspondance documentées. Ne traitez pas la sous-section d'URL comme une expression générique à jokers du shell. Une règle de chemin plus étroite peut l'emporter sur une règle d'hôte plus large.
Pour un aperçu en lecture seule de la configuration de proxy correspondante :
git config --get-urlmatch http.proxy https://git.office.example/team/project.git
Ceci inspecte la correspondance de configuration. Ce n'est pas un test réseau et cela n'établit pas que l'itinéraire est joignable. Tenez compte aussi des autres portées de configuration et des paramètres d'environnement pertinents.
Une redirection n'est pas une nouvelle correspondance de configuration
La documentation de Git indique que les URL mises en correspondance sont celles fournies directement aux commandes Git ; les URL visitées à la suite d'une redirection ne participent pas à cette correspondance. Gardez cette limite en tête si le premier hôte redirige les téléchargements ailleurs.
L'itinéraire doit aussi correspondre au transport. Un dépôt distant SSH n'est pas régi par une sous-section d'URL HTTP simplement parce que le même service propose un site HTTPS.
Utilisez quelques règles intentionnelles, puis inspectez le résultat pour des URL représentatives. Une longue accumulation d'entrées de proxy globales, locales au dépôt et propres à une URL est bien plus difficile à raisonner que la distinction réseau que vous cherchiez à exprimer.