Git

git-config last updated in 2.47.1

NOME

git-config - Obtenha e defina opções globais ou do repositório

RESUMO

git config [<opção-do-arquivo>] [--type=<tipo>] [--fixed-value] [--show-origin] [--show-scope] [-z|--null] <nome> [<valor> [<value-pattern>]]
git config [<opção-do-arquivo>] [--type=<tipo>] --add <nome> <valor>
git config [<opção-do-arquivo>] [--type=<tipo>] [--fixed-value] --replace-all <nome> <valor> [<value-pattern>]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get <nome> [<value-pattern>]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] --get-all <nome> [<value-pattern>]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--fixed-value] [--name-only] --get-regexp <nome_regex> [<value-pattern>]
git config [<opção-do-arquivo>] [--type=<tipo>] [-z|--null] --get-urlmatch <nome> <URL>
git config [<opção-do-arquivo>] [--fixed-value] --unset <nome> [<value-pattern>]
git config [<opção-do-arquivo>] [--fixed-value] --unset-all <nome> [<value-pattern>]
git config [<opção-do-arquivo>] --rename-section <nome_antigo> <novo_nome>
git config [<opção-do-arquivo>] --remove-section <nome>
git config [<opção-do-arquivo>] [--show-origin] [--show-scope] [-z|--null] [--name-only] -l | --list
git config [<opção-do-arquivo>] --get-color nome [<default>]
git config [<opção-do-arquivo>] --get-colorbool <nome> [<stdout-is-tty>]
git config [<opção-do-arquivo>] -e | --edit

DESCRIÇÃO

Você pode consultar, definir, substituir e remover opções com este comando. Na verdade o nome é a seção e a chave são separadas por um ponto, e seu valor será escapado.

Várias linhas podem ser adicionadas a uma opção usando a opção --add. Caso queira atualizar ou cancelar uma opção que possa ocorrer em diversas linhas, será necessário fornecer um valor predefinido (que é uma expressão regular estendida, a menos que a opção --fixed-value seja usada). Somente os valores existentes que correspondem ao padrão são atualizados ou são desmarcados. Caso queira tratar as linhas que não correspondam ao padrão, basta acrescentar um único ponto de exclamação na frente (consulte também EXEMPLOS), mas observe que isso só funciona quando a opção --fixed-value não estiver em uso.

A opção --type=<tipo> instrui o comando git config para garantir que os valores de entrada e na saída sejam canonizados sob o <tipo> informado. Quando nenhum --type=<tipo> é informado, nenhuma canonização será executada. Aqueles que os invocarem podem cancelar a definição de um especificador --type já existente com a opção --no-type.

A leitura destes valores são lidos do sistema nos arquivos de configuração global local e do repositório, é predefinido que as opções --system, --global, --local, --worktree e --file possam ser utilizadas para dizer ao comando para ler somente deste local (consulte ARQUIVOS).

Durante a escrita, é predefinido que o novo valor é gravado no arquivo de configuração local do repositório e as opções --system, --global, --worktree, --file possam ser utilizadas para dizer ao comando para gravar nesse local (você pode dizer --local, porém esta é a predefinição).

Este comando falhará coma condição diferente de zero em caso de erro. Alguns códigos de encerramento são:

A seção ou chave é inválida (ret=1),
nenhuma seção ou nome foi informado (ret=2),
o arquivo de configuração é inválido (ret=3),
o arquivo de configuração não pode ser gravado (ret=4),
você tenta desmarcar uma opção que não existe (ret=5),
você tenta desmarcar ou definir uma opção para a qual várias linhas coincidem (ret=5) ou
você tenta usar um regexp inválido (ret=6).

Em casos bem sucedidos o comando retorna o código 0.

A lista todas as variáveis de configuração disponíveis pode ser obtida utilizando o comando git help --config.

OPÇÕES

--replace-all

O comportamento predefinido é substituir pelo menos uma linha. Isso substitui todas as linhas que coincidam com a chave (e opcionalmente ao value-pattern).

--add

Adiciona uma nova linha à opção sem alterar os valores já existentes. Isso é o mesmo que usar ^$ como o value-pattern em --replace-all.

--get

Obtenha o valor para uma determinada chave (opcionalmente filtrada por uma expressão regular que coincida com o valor). Retorna o código de erro 1 caso a chave não seja encontrada e o último valor caso vários valores da chave sejam encontrados.

--get-all

Como get, mas retorna todos os valores para uma chave com vários valores.

--get-regexp

Como --get-all, contudo, interpreta o nome como uma expressão regular e registra os nomes das chaves. Atualmente, a correspondência das expressões regulares diferencia maiúsculas de minúsculas sendo feita em relação a uma versão canonizada da chave onde os nomes das seções e das variáveis são minúsculos, mas os nomes de subseções não são.

--get-urlmatch <nome> <URL>

Quando é usado um <nome> com duas partes como <seção>.<chave>, é retornado o valor <seção>.<URL>.<chave> cuja parte <URL> corresponda melhor ao URL fornecido (caso este valor não exista, o valor de <seção>.<chave> será usado como contingência). Quando receber apenas a <seção> como o nome, faça isso para todas as chaves na seção e liste-as. Retorna o código de erro 1 caso nenhum valor seja encontrado.

--global

Para escrever opções: escreva para o arquivo global ~/.gitconfig em vez do repositório .git/config, escreva para o arquivo $XDG_CONFIG_HOME/git/config se este arquivo existir e o arquivo ~/.gitconfig não faz.

Para opções de leitura: leia somente do global ~/.gitconfig e de` $XDG_CONFIG_HOME/git/config` ao invés de todos os arquivos disponíveis.

Consulte também ARQUIVOS.

--system

Para opções de escrita: escreva para o $(prefix)/etc/gitconfig do sistema em vez do repositório .git/config.

Para opções de leitura: leia somente do $(prefix)/etc/gitconfig em todo o sistema, e não de todos os arquivos disponíveis.

Consulte também ARQUIVOS.

--local

Para opções de escrita: escreva no arquivo .git/config do repositório. Este é o comportamento predefinido.

Para as opções da leitura: leia somente no repositório .git/config em vez de todos os arquivos disponíveis.

Consulte também ARQUIVOS.

--worktree

Similar ao comando --local exceto quando o $GIT_DIR/config.worktree for lido ou escrito e se extensions.worktreeConfig estiver ativado. Se não estiver, é o mesmo que a opção --local. Observe que $GIT_DIR é igual a $GIT_COMMON_DIR para a árvore principal de trabalho, mas é da forma $GIT_DIR/worktrees/<id>/ nas outras árvores de trabalho. Consulte git-worktree[1] para aprender como ativar o extensions.worktreeConfig.

-f <arquivo-de-config>

--file <arquivo-de-config>

Para as opções de escrita: escreva no arquivo definido em vez do repositório .git/config.

Para as opções da leitura: leia somente no arquivo definido em vez de todos os arquivos disponíveis.

Consulte também ARQUIVOS.

--blob <bolha>

É semelhante à opção --file, mas usa bolha informada em vez de um arquivo. Por exemplo, você pode usar master:.gitmodules para ler os valores do arquivo .gitmodules na ramificação "master". Consulte a seção "DEFININDO AS REVISÕES" do comando gitrevisions[7] para obter uma lista mais completa das diferentes maneiras de se escrever os nomes das bolhas.

--remove-section

Remova a seção dada do arquivo de configuração.

--rename-section

Renomeie a seção dada para um novo nome.

--unset

Remove do arquivo de configuração a linha correspondente à chave.

--unset-all

Remove do arquivo de configuração todas as linhas que correspondam à chave.

-l

--list

Lista todas as variáveis definidas no arquivo de configuração, junto com seus valores.

--fixed-value

Quando utilizado com o argumento value-pattern, trate o value-pattern como uma string exata em vez de uma expressão regular. Isto restringirá os pares nome e o valor que são coincididos apenas com aqueles onde o valor é exatamente igual ao value-pattern.

--type <tipo>

git config irá assegurar que qualquer entrada ou saída é válida sob a(s) restrição(ões) de tipo dada, e irá canonicalizar os valores de saída na forma canônica do <tipo>'s.

Os <tipo>'s válidos incluem:

bool: canoniza os valores como true ou false.
int: canoniza os valores como números decimais simples. Um sufixo opcional com k, m ou g fará com que o valor seja multiplicado por 1024, 1048576 ou 1073741824 na entrada.
bool-or-int: canoniza de acordo com bool ou int, como descrito acima.
path: canonize ao adicionar um sinal ~ no começo para o valor $HOME e ~user no diretório home do usuário especificado. Este especificador não tem efeito durante a definição do valor (porém você pode utilizar o comando git config section.variable ~ / na linha de comando para permitir que o seu shell faça a expansão.)
data validade: canoniza convertendo a partir de uma cadeia com data fixa ou relativa a um registro de data e hora. Este especificador não tem efeito quando for definir o valor.
color: Quando obtiver um valor, canonize através da conversão para uma sequência no padrão ANSI de cor. Ao definir um valor, uma verificação é realizada para garantir que o valor informado seja canonizável como uma cor ANSI, porém será escrito como estiver.

--bool

--int

--bool-or-int

--path

--expiry-date

Opções históricas para selecionar um especificador de tipo. Em vez disso, prefira opção --type (veja acima).

--no-type

Desmarca o especificador de tipo definido anteriormente (caso tenha sido definido antes). Essa opção solicita que o comando git config não canonize a variável recuperada. --no-type não tem efeito sem a opção --type=<tipo> ou --<tipo>.

-z

--null

Para todas as opções que gerem valores e/ou chaves, sempre finalize os valores com o caractere nulo (em vez de uma nova linha). Utilize a nova linha como um delimitador entre chave e valor. Isso permite uma análise segura do que for gerado sem se confundir, por exemplo, através de valores que tenham quebras de linha.

--name-only

Gere apenas os nomes das variáveis de configuração para --list ou --get-regexp.

--show-origin

Aumente a geração de todas as opções de configuração consultadas com o tipo da origem (arquivo, entrada padrão, blob, linha de comando) e a origem real (o caminho do arquivo de configuração, da "ref" ou a ID da bolha, caso seja aplicável).

--show-scope

Semelhante a opção --show-origin, na medida em que aumenta a saída de todas as opções de configuração consultadas com o escopo deste valor (worktree, local, global, system, command).

--get-colorbool <nome> [<stdout-is-tty>]

Localize a configuração de cor para <nome> (color.diff por exemplo) e mostre true ou false. <stdout-is-tty> deve ser true ou false sendo levado em consideração quando a configuração for auto. Se <stdout-is-tty> estiver ausente, a saída padrão do próprio comando será verificada e encerrará com a condição 0 se a cor for usada, ou caso contrário, encerrará com a condição 1. Quando a configuração de cor para name for indefinida, o comando usa color.ui como contingência.

--get-color <nome> [<padrão>]

Localize a cor configurada para name (color.diff.new por exemplo) e emita-a como a uma sequência de escape com cores ANSI na saída predefinida. O parâmetro opcional default é usado em seu lugar, caso não haja nenhuma cor configurada para name.

--type=color [--default=<default>] é preferível em vez de --get-color (porém repare que a opção --get-color omitirá a nova linha impressa por --type=color).

-e

--edit

Abre um editor para alterar o arquivo de configuração informado; ou --system, --global ou repositório (predefinido).

--[no-]includes

Respeite as diretivas include.* nos arquivos de configuração ao procurar pelos valores. A predefinição retorna para off quando determinado arquivo seja informado (por exemplo, usando os comandos --file, --global, etc) e ao pesquisar por todos os arquivos de configuração.

--default <valor>

Ao usar --get e a variável solicitada não for encontrada, comportar-se como se o <valor> fosse o valor atribuído à variável.

CONFIGURAÇÃO

O pager.config só é respeitado ao listar a configuração, ou seja, ao usar --list ou qualquer um dos --get-* que podem retornar vários resultados. A predefinição é usar um pager.

ARQUIVOS

É predefinido que o comado git config leia as opções de configuração a partir de diversos arquivos:

$(prefix)/etc/gitconfig: Arquivo de configuração do sistema.
$XDG_CONFIG_HOME/git/config
~/.gitconfig: Arquivos de configuração específicos do usuário. Quando a variável de ambiente XDG_CONFIG_HOME não estiver definida ou estiver vazia, $HOME/.config/ será usado como $XDG_CONFIG_HOME.

Eles também são chamados de arquivos de configuração "globais". Caso ambos existam, eles serão lidos na ordem indicada acima.
$GIT_DIR/config: Arquivo de configuração específico do repositório.
$GIT_DIR/config.worktree: Isso é opcional e só é pesquisado quando o arquivo extensions.worktreeConfig está presente em $GIT_DIR/config.

Você também poderá fornecer parâmetros adicionais de configuração ao executar qualquer comando git usando a opção -c. Consulte git[1] para obter mais detalhes.

As opções serão lidas a partir de todos os arquivos disponíveis. Caso os arquivos de configuração global ou de todo o sistema estiverem ausentes ou ilegíveis, eles serão ignorados. Se o arquivo de configuração do repositório estiver ausente ou ilegível, o comando git config encerrará com um código de erro diferente de zero. Uma mensagem de erro será produzida caso o arquivo esteja ilegível, mas não se estiver ausente.

Os arquivos são lidos na ordem indicada acima, com o último valor encontrado tendo precedência sobre os valores lidos anteriormente. Quando vários valores são obtidos, serão usados todos os valores de uma chave de todos os arquivos.

É predefinido que as opções sejam gravadas apenas no arquivo específico de configuração do repositório. Observe que isso também afeta opções como --replace-all e --unset. O comando git config só alterará um arquivo por vez.

Você pode limitar quais fontes de configuração são lidas ou quais serão gravadas ao definir o caminho de um arquivo com a opção --file ou especificando um escopo de configuração com a opção --system, --global, --local ou --worktree. Para mais informações, consulte OPÇÕES acima.

ESCOPOS

Cada fonte de configuração está dentro de um escopo de configuração. Os escopos são:

system: $(prefix)/etc/gitconfig
global: $XDG_CONFIG_HOME/git/config

~/.gitconfig
local: $GIT_DIR/config
árvore de trabalho: $GIT_DIR/config.worktree
comando: GIT_CONFIG_{COUNT,KEY,VALUE} variáveis de ambiente (consulte VARIÁVEIS DO AMBIENTE abaixo)

a opção -c

Com exceção do command, cada escopo corresponde a uma opção da linha de comando: --system, --global, --local, --worktree.

Ao ler as opções, ao especificar um escopo lerá apenas as opções dos arquivos que estejam dentro deste escopo. Ao gravar as opções, ao especificar um escopo ele será gravado nos arquivos dentro deste escopo (em vez do arquivo de configuração específico do repositório). Consulte OPÇÕES acima para obter uma descrição completa.

Independentemente da definição do escopo, a maioria das opções de configuração são respeitadas, porém, algumas opções são respeitadas apenas em determinados escopos. Consulte a documentação da respectiva opção para obter mais informações.

Configuração protegida

A configuração protegida refere-se aos escopos system, global e command. Por motivos de segurança, determinadas opções são respeitadas somente quando são especificadas numa configuração protegida, caso contrário são ignoradas.

O Git trata estes escopos como se fossem controlados pelo usuário ou por um administrador confiável. Isso ocorre porque um invasor que controla esses escopos pode causar danos substanciais sem usar o Git, portanto, presume-se que o ambiente do usuário proteja estes escopos contra invasores.

VARIÁVEIS DO AMBIENTE

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM: Obtenha a configuração dos arquivos informados em vez da configuração global ou no nível do sistema. Para mais detalhes, consulte git[1].
GIT_CONFIG_NOSYSTEM: Independente se você vai ignorar as configurações de leitura do arquivo $(prefix)/etc/gitconfig do sistema. Para mais detalhes, consulte git[1].

Consulte também ARQUIVOS.

GIT_CONFIG_COUNT
GIT_CONFIG_KEY_<n>
GIT_CONFIG_VALUE_<n>: Caso GIT_CONFIG_COUNT seja definido como um número positivo, todos os pares do ambiente GIT_CONFIG_KEY_<n> e GIT_CONFIG_VALUE_<n> até esse número serão adicionados à configuração durante a execução do processo. Os pares de configuração são indexados por zero. Qualquer chave ou valor ausente são tratados como erro. Um GIT_CONFIG_COUNT vazio é tratado da mesma maneira que GIT_CONFIG_COUNT=0, ou seja, nenhum par é processado. Estas variáveis de ambiente substituirão os valores nos arquivos de configuração, mas serão substituídas por quaisquer opções explícitas passadas através do comando git -c.

É útil para os casos onde você queira gerar vários comandos git com uma configuração comum, porém não pode depender de um arquivo de configuração, ao escrever scripts por exemplo.
GIT_CONFIG: Caso nenhuma opção --file seja usada com git config, utilize o arquivo fornecido por GIT_CONFIG como se ele fosse fornecido através da opção --file. Esta variável não tem efeito nos outros comandos Git e é principalmente utilizado por questão de compatibilidade histórica; geralmente não há motivo para utilizá-lo no lugar da opção ‘--file’.

EXEMPLOS

Dado um .git/config como este:

#
# Este é o arquivo de configuração e
# um caractere '#' ou ';' serve como
# um comentário
#

; variáveis principais
[core]
	; Não confie nos modos dos arquivos
	filemode = false

; Nosso próprio algorítimo diff
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

; Configurações de proxy
[core]
	gitproxy=proxy-command for kernel.org
	gitproxy=default-proxy ; for all the rest

; HTTP
[http]
	sslVerify
[http "https://weak.example.com"]
	sslVerify = false
	cookieFile = /tmp/cookie.txt

você pode definir o filemode como true com

% git config core.filemode true

As hipotéticas entradas de comando do proxy realmente têm um postfix para discernir a qual URL elas se aplicam. Aqui um exemplo de como alterar a entrada do kernel.org para "ssh".

% git config core.gitproxy '"ssh" for kernel.org' 'for kernel.org$'

Isso garante que apenas o par de chave/valor do kernel.org seja substituído.

Para excluir a entrada para renomear, faça

% git config --unset diff.renames

Caso queira excluir uma entrada para um "multivar" (como core.gitproxy acima), é necessário fornecer um regex que coincida com o valor exato de uma linha.

Para consultar o valor para uma determinada chave, faça

% git config --get core.filemode

% git config core.filemode

ou, para consultar um multivar:

% git config --get core.gitproxy "for kernel.org$"

Caso queira conhecer todos os valores de um multivar, faça:

% git config --get-all core.gitproxy

Caso queira viver perigosamente, é possível substituir all core.gitproxy por um novo com

% git config --replace-all core.gitproxy ssh

No entanto, caso queira realmente substituir apenas a linha pelo proxy predefinido, ou seja, aquele sem um "for …" postfix, faça algo assim:

% git config core.gitproxy ssh '! for '

Para que haja a real coincidência apenas com os valores de um ponto de exclamação, é necessário

% git config section.key value '[!]'

Para adicionar um novo proxy, sem alterar qualquer outro já existente, utilize

% git config --add core.gitproxy '"proxy-command" for example.com'

Um exemplo para usar cores personalizadas da configuração em seu script:

#!/bin/sh
WS=$(git config --get-color color.diff.whitespace "blue reverse")
RESET=$(git config --get-color "" "reset")
echo "${WS}your whitespace color or blue reverse${RESET}"

Para URLSs em https://weak.example.com, http.sslVerify está definido como false, enquanto está definido para true para todos os outros:

% git config --type=bool --get-urlmatch http.sslverify https://good.example.com
true
% git config --type=bool --get-urlmatch http.sslverify https://weak.example.com
false
% git config --get-urlmatch http https://weak.example.com
http.cookieFile /tmp/cookie.txt
http.sslverify false

ARQUIVO DE CONFIGURAÇÃO

O arquivo de configuração do Git contém várias variáveis que afetam o comportamento dos comandos do Git. Os arquivos .git/config e opcionalmente config.worktree (consulte a seção "ARQUIVO DE CONFIGURAÇÃO" do git-worktree[1]) em cada repositório são utilizados para armazenar a configuração para aquele repositório e o $HOME/.gitconfig é utilizado para armazenar uma configuração por usuário como valores alternativos para o arquivo .git/config. O arquivo /etc/gitconfig pode ser utilizado para armazenar a predefinição de uma configuração em todo o sistema.

As variáveis de configuração são usadas pelos comandos Git plumbing e porcelain. As variáveis são divididas em seções, sendo que o nome na variável totalmente qualificada da própria variável é o último segmento separado por pontos e o nome da seção é tudo o que vem antes do último ponto. Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas caracteres alfanuméricos e -, devem começar com um caractere alfabético. Algumas variáveis podem aparecer diversas vezes; dizemos então que a variável é multivalorada.

Sintaxe

The syntax is fairly flexible and permissive. Whitespace characters, which in this context are the space character (SP) and the horizontal tabulation (HT), are mostly ignored. The # and ; characters begin comments to the end of line. Blank lines are ignored.

O arquivo consiste em seções e variáveis. Uma seção começa com o nome da seção entre colchetes e continua até o início da próxima seção. Os nomes das seções não diferenciam maiúsculas de minúsculas. Apenas caracteres alfanuméricos, - e . são permitidos nos nomes das seções. Cana variável deve pertencer a alguma seção, o que significa que deve haver um cabeçalho da seção antes da primeira configuração de uma variável.

As seções podem ser divididas em subseções. Para iniciar uma subseção, coloque seu nome entre aspas duplas, separado pelo espaço do nome da seção no cabeçalho da seção, como mostra o exemplo abaixo:

	[seção "subseção"]

Os nomes da subseção diferem maiúsculas de minúsculas e podem conter qualquer caractere, exceto o caracter de nova linha e byte nulo. Aspas duplas " e a barra invertida podem ser incluídas escapando-as como \\" e \\, respectivamente. As barras invertidas que precedam outros caracteres, são eliminadas durante a leitura; por exemplo, t e \0 são lidos como 0. Os cabeçalhos da seção não podem abranger diversas linhas. As variáveis podem pertencer diretamente a uma seção ou a uma determinada subseção. Você pode ter [seção] se tiver [seção "subseção"], mas não é necessário.

Também existe uma sintaxe obsoleta [section.subsection]. Com esta sintaxe o nome da subseção é convertido em minúsculas e também é comparado com distinção entre maiúsculas e minúsculas. Estes nomes de subseções seguem as mesmas restrições que os nomes de seção.

Todas as outras linhas (e o restante da linha após o cabeçalho da seção) são reconhecidas como variáveis de definição, no formulário name = valor (ou apenas name, que é um atalho para dizer que a variável é um booleano "true"). Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas caracteres alfanuméricos e -, devem começar com um caractere alfabético.

Whitespace characters surrounding name, = and value are discarded. Internal whitespace characters within value are retained verbatim. Comments starting with either # or ; and extending to the end of line are discarded. A line that defines a value can be continued to the next line by ending it with a backslash (\); the backslash and the end-of-line characters are discarded.

If value needs to contain leading or trailing whitespace characters, it must be enclosed in double quotation marks ("). Inside double quotation marks, double quote (") and backslash (\) characters must be escaped: use \" for " and \\ for \.

As seguintes sequências com caracteres de escape (além de \" e \\) são reconhecidas: \n para caractere de nova linha (NL), \t para tabulação horizontal (HT, TAB) e \b para backspace (BS). Outras seqüências com caracteres de escape (incluindo sequências de fuga octal) são inválidas.

Inclui

As seções include e includeIf permitem que você inclua diretivas da configuração de outra fonte. Estas seções se comportam de forma idêntica, com exceção das seções includeIf que podem ser ignorados se a sua condição não for avaliada como verdadeira; consulte "Inclusão condicional" abaixo.

Você pode incluir um arquivo da configuração de outro configurando a variável especial include.path (ou includeIf.*.path) como o nome do arquivo a ser incluído. A variável assume um nome do caminho como seu valor e está sujeita à expansão do til. Estas variáveis podem ser utilizadas várias vezes.

O conteúdo do arquivo incluído é inserido imediatamente como se tivessem sido encontrados no local da diretiva incluir. Se o valor na variável for um caminho relativo, o caminho será considerado relativo ao arquivo de configuração onde a diretiva include foi encontrada. Veja os exemplos abaixo.

Inclusão condicional

Você pode condicionalmente incluir um arquivo da configuração de um outro condicionalmente definindo uma variável includeIf.<condição>.path para o nome do arquivo que será incluído.

A condição começa com uma palavra-chave seguida de dois pontos e alguns dados cujo formato e significado dependem da palavra-chave. As palavras-chave compatíveis são:

gitdir

Os dados que seguem a palavra-chave gitdir: são utilizados como um padrão de agrupamento. Caso o local do diretório .git coincida com o padrão, a condição de inclusão será atendida.

O local .git pode ser descoberto automaticamente ou vir da variável de ambiente $GIT_DIR. Caso o repositório seja descoberto automaticamente por meio de um arquivo .git (de submódulos ou uma árvore de trabalho vinculada por exemplo), o local .git será o local final onde está o diretório .git, e não onde o arquivo git está.

O padrão pode conter curingas de mascaramento padrão e dois adicionais, **/ e /**, que podem coincidir com diversos componentes do caminho. Para mais detalhes, consulte o gitignore[5] para detalhes. Por conveniência:

Caso o padrão comece com ~/, ~ será substituído com o conteúdo da variável de ambiente HOME.
Caso o padrão comece com ./, é substituído com o diretório contendo o arquivo da configuração atual.
Caso o padrão não comece com com nenhum ~/, ./ ou /, **/ será anexado automaticamente. O padrão foo/bar se torna **/foo/bar e coincidirá com /qualquer/caminho/para/foo/bar por exemplo.
Caso o padrão termine com /, ** será adicionado automaticamente. O padrão foo/ se torna foo/** por exemplo. Em outras palavras, ele combina "foo" e tudo dentro, recursivamente.

gitdir/i

É o mesmo que gitdir exceto que a coincidência é feita sem distinguir as maiúsculas das minusculas (em sistemas onde seja indiferente o sistema de arquivos não se importa com maiúsculas de minusculas)

onbranch

Os dados que seguem a palavra-chave onbranch: são considerados um padrão com curingas de agrupamento padrão e dois curingas adicionais, **/ e /**, que podem corresponder a vários componentes de caminho. Se estivermos numa árvore de trabalho onde o nome do ramo que está sendo verificado no momento corresponda ao padrão, a condição de inclusão será atendida.

Caso o padrão termine com /, ** será adicionado automaticamente. O padrão foo/ se torna foo/** por exemplo. Em outras palavras, ele coincide com todos os ramos que começam com foo/. Isso é útil pois caso as suas ramificações estejam organizadas hierarquicamente e você queira aplicar uma configuração em todas as ramificações nesta hierarquia.

hasconfig:remote.*.url:

Os dados que seguem esta palavra-chave são tomados como um padrão com curingas e dois adicionais, **/ e /**, que podem corresponder com vários componentes. A primeira vez que esta palavra-chave for vista, o resto dos arquivos de configuração serão verificados com as URLs remotas (sem aplicar nenhum valor). Se existir pelo menos uma URL remota que corresponda a este padrão, a condição de inclusão será satisfeita.

Os arquivos inclusos por esta opção (direta ou indiretamente) não podem conter URLs remotas.

Note que, ao contrário de outras condições, resolver essa condição depende de informações que ainda não são conhecidas no momento da leitura da condição. Um caso de uso típico é que essa opção está presente como uma configuração a nível de sistema ou uma configuração de global, a URL remota está em uma configuração de nível local; daí a necessidade de digitalizar à frente ao resolver essa condição. A fim de evitar conflitos onde os arquivos incluídos podem afetar se tais arquivos estão potencialmente inclusos, o Git quebra o ciclo, proibindo estes arquivos de afetar a resolução destas condições (assim, proibindo-os de declarar URLs remotas).

Quanto a nomenclatura dessa palavra-chave, ela é compatível com um esquema de nomenclatura compatível com mais condições de inclusão com base em variáveis, mas, atualmente o Git suporta apenas a palavra-chave exata descrita acima.

Algumas poucas anotações sobre coincidir através de gitdir e gitdir/i:

Os "symlinks" (links simbólicos) em $GIT_DIR não são resolvidos antes que sejam coincididos.
Ambas as versões do "symlink" (links simbólico) e do "realpath" (caminho real) dos caminhos serão coincididos fora do $GIT_DIR. Por exemplo, caso ~/git seja um link simbólico para /mnt/storage/git, ambos os gitdir:~/git e gitdir:/mnt/storage/git coincidirão.

Este não foi o caso no lançamento inicial desse recurso na versão v2.13.0, que coincidia apenas à versão do caminho real. A configuração que queira ser compatível com o lançamento inicial deste recurso precisa definir apenas a versão do caminho real ou das duas versões.
Note que "../" não é especial e não irá coincidir literalmente, o que não é o que você quer.

Exemplo

# Principais variáveis
[core]
	; Não confie nos modos dos arquivos
	filemode = false

# Nosso algoritmo diff
[diff]
	external = /usr/local/bin/diff-wrapper
	renames = true

[ramo "devel"]
	remote = origin
	merge = refs/heads/devel

# Configurações de proxy
[core]
	gitProxy="ssh" for "kernel.org"
	gitProxy=default-proxy ; for the rest

[include]
	path = /path/to/foo.inc ; incluído através de um caminho absoluto
	path = foo.inc ; find "foo.inc" relativo ao arquivo atual
	path = ~/foo.inc ; find "foo.inc" no seu diretório `$HOME`

; inclua caso $GIT_DIR seja /path/to/foo/.git
[includeIf "gitdir:/path/to/foo/.git"]
	path = /path/to/foo.inc

; inclua em todos os repositórios dentro do /path/to/group
[includeIf "gitdir:/path/to/group/"]
	path = /path/to/foo.inc

; inclua em todos os repositórios dentro do $HOME/to/group
[includeIf "gitdir:~/to/group/"]
	path = /path/to/foo.inc

; os caminhos relativos são sempre relativos à inclusão
; do arquivo (caso a condição seja verdadeira); a sua localização não é
; afetada pela condição
[includeIf "gitdir:/path/to/group/"]
	path = foo.inc

; inclua apenas caso estejamos em uma árvore de trabalho
; onde "foo-branch" seja verificado
[includeIf "onbranch:foo-branch"]
	path = foo.inc

; inclua apenas caso exista um ramo remoto com a URL fornecida (observe
; que tal URL pode ser fornecida posteriormente num arquivo ou num
; arquivo lido após este arquivo ser lido, como visto neste exemplo)
[includeIf "hasconfig:remote.*.url:https://example.com/**"]
	path = foo.inc
[remote "origin"]
	url = https://example.com/git

Valores

Os Valores das várias variáveis são tratadas como uma cadeia de caracteres simples, porém existem variáveis que pegam os valores de tipos específicos e existem regras de como soletrá-los.

booleano

Quando uma variável pega um valor booleano, muitos sinônimos são aceitos para true e false, estes são todos insensíveis as mudanças de maiúsculas e minusculas.

verdadeiro: Os valores válidos para verdadeiro num literal booleano são yes, on, true e 1. Além disso, uma variável definida sem um valor = <valor> é considerado como verdadeiro.
falso: Os falsos literais booleanos são no, off, false, 0 e a string vazia.

Quando converter um valor para a sua forma canônica utilizando o --type=bool, tipo de especificação git config se assegurará que a saída seja true ou false (em minusculas).

inteiro

O valor das muitas variáveis que determinam os vários tamanhos podem ter como sufixo k, M,… que significa "escale o número por 1024", "por 1024x1024", etc.

color

O valor de uma variável que pega uma cor de uma lista de cores (ao menos duas, uma para o primeiro plano e outra para o plano de fundo) e os atributos (quantos queira), separados por espaços.

São aceitas as seguintes cores básicas normal, black, red, green, yellow, blue, magenta, cyan, white e default. A primeira cor informada é o primeiro plano; a segunda é o plano de fundo. Todas as cores básicas, exceto normal e default, têm uma variação brilhante que pode ser especificada prefixando a cor com bright, como brightred.

A cor normal não faz qualquer alteração na cor. É o mesmo que uma string vazia mas pode ser usada como a cor do primeiro plano ao definir apenas uma cor de fundo ("normal red" por exemplo).

A cor default repõe explicitamente a cor predefinida do terminal, por exemplo, para definir um fundo sem cor. Embora varie entre os terminais, isso normalmente não é o mesmo que definir para "white black" (branco preto).

Colors may also be given as numbers between 0 and 255; these use ANSI 256-color mode (but note that not all terminals may support this). If your terminal supports it, you may also specify 24-bit RGB values as hex, like #ff0ab3, or 12-bit RGB values like #f1b, which is equivalent to the 24-bit color #ff11bb.

Os atributos aceitos são bold, dim, ul, blink, reverse, italic e strike (para letras tachadas ou "strikethrough"). É indiferente a posição de qualquer atributo com relação às cores (antes, depois ou no meio). Atributos específicos podem ser desativados prefixando-os com no ou no- (por exemplo, noreverse, no-ul etc.).

O pseudo-atributo reset redefine todas as cores e os atributos antes de aplicar a cor definida. Por exemplo, o reset green resultará em um primeiro plano verde e o fundo padrão sem qualquer atributo ativo.

Uma sequência de cores vazias não produz nenhum efeito de cor. Isso pode ser utilizado para evitar colorir elementos específicos sem desabilitar totalmente a cor.

Para os espaços de cor predefinidos do git, os atributos devem ser redefinidos no início de cada item da saída colorida. Portanto, a configuração de color.decorate.branch como black pintará o nome da ramificação como black, mesmo que o item anterior na mesma linha de saída (abrir parênteses antes da lista de nomes de ramificações na saída log --decorate por exemplo) esteja configurado para ser pintado com bold ou algum outro atributo. No entanto, os formatos de registro personalizados podem fazer uma coloração mais complicada e em camadas, nesse caso, as formas negadas podem ser úteis.

caminho do diretório

Uma variável que recebe um valor para o nome do caminho pode receber uma cadeia de caracteres que começa com "~/" ou "~user/", a expansão usual do til acontece com essa cadeia de caracteres: ~/ é expandida para o valor $HOME, e ~user/ para o diretório inicial do usuário que foi definido.

Caso um caminho comece com %(prefixo)/, o restante será interpretado como um caminho em relação ao "prefixo de tempo de execução" do Git, ou seja, em relação ao local onde o próprio Git foi instalado. Por exemplo, %(prefixo)/bin/ refere-se ao diretório onde o próprio executável Git está. Se o Git for compilado sem suporte ao "runtime prefix support" (prefixo de tempo de execução), o prefixo compilado será substituído. No caso improvável de que um caminho literal precise ser especificado e que não_ deva_ser expandido, ele precisa ser prefixado por ./, assim: ./%(prefixo)/bin.

Variáveis

Observe que essa lista não é abrangente e não está necessariamente completa. Para variáveis específicas de comando, você encontrará uma descrição mais detalhada na página apropriada do manual.

Outras ferramentas relacionadas ao git podem usar e usam as suas próprias variáveis. Ao inventar novas variáveis para uso em sua própria ferramenta, certifique-se que seus nomes não entrem em conflito com aqueles usados pelo próprio Git e por outras ferramentas populares, descreva-os em sua própria documentação.

Warning

Missing pt_BR/config/add.txt