Dê ao Git regras de proxy diferentes para hosts diferentes

A configuração HTTP específica por URL do Git pode manter um serviço interno direto enquanto preserva um proxy noutro local. Inspecione o resultado da correspondência para o URL exato.

Uma única configuração do Git pode servir duas rotas bem diferentes: um host externo alcançado através de um proxy aprovado e um host interno alcançado diretamente. Não precisa de editar o valor global predefinido sempre que muda de repositório.

O Git suporta configuração HTTP específica por URL. Por exemplo:

[http]
    proxy = http://proxy.example:8080
[http "https://git.office.example/"]
    proxy =

Para um repositório público externo onde os proxies públicos são permitidos, a lista de proxies HTTP oferece candidatos para o endpoint predefinido. O valor vazio é uma substituição explícita para o URL correspondente. É diferente de eliminar essa chave mais específica, o que pode voltar a expor o proxy genérico.

Faça corresponder o URL que o Git usa

O esquema, o nome do host, a porta, o caminho e o nome de utilizador opcional participam nas regras de correspondência documentadas. Não trate a subsecção de URL como uma expressão genérica de carateres curinga da shell. Uma regra de caminho mais estreita pode vencer uma regra de host mais ampla.

Para uma vista apenas de leitura da configuração de proxy correspondente:

git config --get-urlmatch http.proxy https://git.office.example/team/project.git

Isto inspeciona a correspondência de configuração. Não é um teste de rede nem estabelece que a rota seja alcançável. Tenha também em conta outros âmbitos de configuração e definições de ambiente relevantes.

Um redirecionamento não é uma nova correspondência de configuração

A documentação do Git diz que os URL correspondidos são os fornecidos diretamente aos comandos do Git; os URL visitados devido a um redirecionamento não participam nessa correspondência. Tenha essa limitação em conta se o primeiro host redirecionar transferências para outro local.

A rota também deve corresponder ao transporte. Um remoto SSH não é regido por uma subsecção de URL HTTP só porque o mesmo serviço oferece um site HTTPS.

Use algumas regras intencionais e depois inspecione o resultado para URL representativos. Uma longa acumulação de entradas de proxy globais, locais ao repositório e específicas por URL é muito mais difícil de raciocinar do que a distinção de rede que tentava expressar.

Artigos relacionados