Git

git-config last updated in 2.45.0

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.

Multiple lines can be added to an option by using the --add option. If you want to update or unset an option which can occur on multiple lines, a value-pattern (which is an extended regular expression, unless the --fixed-value option is given) needs to be given. Only the existing values that match the pattern are updated or unset. If you want to handle the lines that do not match the pattern, just prepend a single exclamation mark in front (see also EXEMPLOS), but note that this only works when the --fixed-value option is not in use.

The --type=<type> option instructs git config to ensure that incoming and outgoing values are canonicalize-able under the given <type>. If no --type=<type> is given, no canonicalization will be performed. Callers may unset an existing --type specifier with --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).

This command will fail with non-zero status upon error. Some exit codes are:

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

Adds a new line to the option without altering any existing values. This is the same as providing ^$ as the value-pattern in --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

Like --get-all, but interprets the name as a regular expression and writes out the key names. Regular expression matching is currently case-sensitive and done against a canonicalized version of the key in which section and variable names are lowercased, but subsection names are not.

--get-urlmatch <nome> <URL>

When given a two-part <name> as <section>.<key>, the value for <section>.<URL>.<key> whose <URL> part matches the best to the given URL is returned (if no such key exists, the value for <section>.<key> is used as a fallback). When given just the <section> as name, do so for all the keys in the section and list them. Returns error code 1 if no value is found.

--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

For writing options: write to the repository .git/config file. This is the default behavior.

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>

Similar to --file but use the given blob instead of a file. E.g. you can use master:.gitmodules to read values from the file .gitmodules in the master branch. See "SPECIFYING REVISIONS" section in gitrevisions[7] for a more complete list of ways to spell blob names.

--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

Un-sets the previously set type specifier (if one was previously set). This option requests that git config not canonicalize the retrieved variable. --no-type has no effect without --type=<type> or --<type>.

-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>]

Find the color setting for <name> (e.g. color.diff) and output "true" or "false". <stdout-is-tty> should be either "true" or "false", and is taken into account when configuration says "auto". If <stdout-is-tty> is missing, then checks the standard output of the command itself, and exits with status 0 if color is to be used, or exits with status 1 otherwise. When the color setting for name is undefined, the command uses color.ui as fallback.

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

Find the color configured for name (e.g. color.diff.new) and output it as the ANSI color escape sequence to the standard output. The optional default parameter is used instead, if there is no color configured for 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

Opens an editor to modify the specified config file; either --system, --global, or repository (default).

--[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

pager.config is only respected when listing configuration, i.e., when using --list or any of the --get-* which may return multiple results. The default is to use a 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.

The files are read in the order given above, with last value found taking precedence over values read earlier. When multiple values are taken then all values of a key from all files will be used.

É 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.

You can limit which configuration sources are read from or written to by specifying the path of a file with the --file option, or by specifying a configuration scope with --system, --global, --local, or --worktree. For more, see OPÇÕES above.

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

Protected configuration refers to the system, global, and command scopes. For security reasons, certain options are only respected when they are specified in protected configuration, and ignored otherwise.

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 utilizadas pelo encanamento Git e pelos comandos porcelana. As variáveis são divididas em seções em que o nome completo da variável da variável em si é o último segmento separado por ponto e o nome da seção é tudo que estiver antes do último ponto. Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas os caracteres alfanuméricos e - que devem começar com um caractere alfabético. Algumas variáveis podem aparecer várias vezes; dizemos então que a variável possui diversos valores.

Sintaxe

A sintaxe é bastante flexível e permissiva; os espaços são ignorados na maioria das vezes. Os caracteres # e ; define o começo dos comentários até o final da linha, as linhas em branco são ignoradas.

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é a próxima seção. Os nomes de seção não diferenciam as maiúsculas das minúsculas. Apenas os caracteres alfanuméricos, - e . são permitidos nos nomes das seções. Cada 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 por um espaço do nome da seção, no cabeçalho da seção, como no exemplo abaixo:

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

Os nomes das subseções diferenciam as maiúsculas das minúsculas, podem conter qualquer caractere, exceto os que definem uma nova linha e um byte nulo. As aspas duplas " e a barra invertida podem ser incluídas escapando-as como` \"` e \\ respectivamente. As barras invertidas anteriores aos outros caracteres são descartadas durante a leitura; por exemplo, \t é lido como` t` e \0 é lido como 0. Os cabeçalhos da seção não podem abranger várias linhas. As variáveis podem pertencer diretamente a uma seção ou a uma determinada subseção. Você pode ter [section] caso tenha [section "subsection"], 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 configuração, no formato name=value (ou apenas name, que é uma abreviação para dizer que a variável é um valor booleano true). Os nomes das variáveis não diferenciam maiúsculas de minúsculas, permitem apenas os caracteres alfanuméricos e - que devem começar com um caractere alfabético.

Uma linha que define um valor pode ser continuada para a próxima linha, terminando com um \; a barra inclinada e o final da linha são removidos. São descartados os espaços à esquerda após name=, o restante da linha após o primeiro caractere de comentário # ou ; e os espaços à direita da linha a menos que estejam entre aspas duplas. Internamente os espaços com valores são retidos de forma literal.

Dentro de uma aspa dupla " e barra invertida \ os caracteres podem ser utilizados literalmente: utilize \" para " e \\ para \.

As seguintes sequências de escape (ao lado de \" e \\) são reconhecidos: \n para caracteres de nova linha (NL), \t para tabulação horizontal (HT, TAB) e \b para o backspace (BS). São validas também as outras sequências de escape de caracteres (incluindo sequências de escape octais).

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 tivesse sido encontrado no local da diretiva de inclusão. Caso o valor da variável seja um caminho relativo, o caminho será considerado relativo ao arquivo da configuração no qual a diretiva de inclusão 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 caracteres curinga de mascaramento predefinidos e dois adicionais, **/ e /**, que podem coincidir com vários componentes do caminho. Caso estejamos em uma árvore de trabalho cujo nome do ramo atual com check-out coincida com o padrão, a inclusão condicional 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 verdadeiros literais booleanos são yes, on, true e 1. Além disso, é considerada como verdadeira uma variável definida sem = <valor>.
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.

As cores básicas que são aceitas são normal (normal), black (preto) , red (vermelho) , green (verde), yellow (amarelo) , blue (azul), magenta (magenta), cyan (ciano), white (branco) e default (predefinido). A primeira cor é o primeiro plano; a segunda é o plano de fundo. Todas as cores básicas, exceto normal e default, possuem uma variante brilhante da cor que pode ser definida com bright, assim 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).

As cores também podem ser utilizadas como números entre 0 e 255; estes usam o modo ANSI com 256 cores (note que nem todos os terminais são compatíveis). Caso o seu terminal seja compatível, você também pode definir os valores RGB de 24 bits como hexadecimais, #ff0ab3 por exemplo.

Os atributos compatíveis são bold, dim, ul, blink, reverse, italic, e strike (para letras cruzadas ou "rasuradas"). A posição de qualquer atributo em relação às cores (antes, depois ou entre) não importa. 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 slots com as cores predefinidas do git, os atributos devem ser redefinidos no início de cada item na saída colorida. Portanto ao definir a variável color.decorate.branch como` black` pintará esse nome do ramo como preto simples, mesmo se a coisa anterior na mesma linha de saída (abrir parênteses antes da lista dos nomes das ramificações na saída de log --decorate por exemplo) é definido para ser pintado com bold (negrito) ou algum outro atributo. No entanto, os formatos dos registros log personalizados podem fazer uma coloração mais complicada e em camadas, as formas negadas podem ser úteis lá.

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 esta lista não é abrangente e não está completa. Para variáveis específicas do comando, você encontrará uma descrição mais detalhada na página apropriada do manual.

Outras ferramentas relacionadas ao git-related podem usar as suas próprias variáveis. Ao inventar novas variáveis para utilização em sua própria ferramenta, certifique-se que os seus respectivos nomes não entram em conflito com os que já são utilizados pelo próprio Git e outras ferramentas populares, e descreva-os em sua documentação.

Warning

Missing pt_BR/config/advice.txt