Git

git-config last updated in 2.43.0

NOME

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

RESUMO

git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] nome [valor [value_regex]]
git config [<opção-do-arquivo>] [--type=<tipo>] --add nome valor
git config [<opção-do-arquivo>] [--type=<tipo>] --replace-all nome valor [value_regex]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] --get nome [value_regex]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] --get-all nome [value_regex]
git config [<opção-do-arquivo>] [--type=<tipo>] [--show-origin] [--show-scope] [-z|--null] [--name-only] --get-regexp name_regex [value_regex]
git config [<opção-do-arquivo>] [--type=<tipo>] [-z|--null] --get-urlmatch nome URL
git config [<opção-do-arquivo>] --unset nome [value_regex]
git config [<opção-do-arquivo>] --unset-all nome [value_regex]
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 utilizando a opção --add. Caso queira atualizar ou remover alguma opção que pode ocorrer em várias linhas, é necessário usar um POSIX regexp value_regex. Apenas os valores existentes que correspondam à um regexp são atualizados ou não definidos. Caso queira manipular as linhas que não correspondam ao regex, basta colocar um único ponto de exclamação na frente (consulte também [EXEMPLOS]).

A opção --type=<tipo> instrui o git config para garantir que os valores que chegam e os que saem sejam canonicamente compatíveis com o <tipo>. Caso nenhum --type=<tipo> seja utilizado, nenhuma canonização será realizada. Os autores dos chamados podem desconfigurar um --type 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á com uma condição diferente de zero em caso de erro. Alguns códigos de saída 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.

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_regex").

--add

Adiciona uma nova linha à opção, sem alterar nenhum valor já existente. É o mesmo que informar ^$ como o valor_regex na opção --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 a opção --get-all, porém interpreta o nome como uma expressão regular e escreve os nomes das chaves. A coincidência comum da expressão regular é sensível a maiúsculas e minúsculas, é feita contra uma versão canonizado da chave onde a seção e os nomes das variáveis são minúsculas, porém os nomes das subseções não são.

--get-urlmatch nome URL

Quando é utilizado em um nome com duas partes section.key, o valor da section.<url>.key cuja parte da <url> coincida para o retorno da melhor URL informada (caso essa chave não exista, o valor do section.key será usado como substituto). Quando receber apenas a seção como nome, faça-o para todas as chaves da 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 $(prefixo)/etc/gitconfig do sistema em vez do repositório .git/config.

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

Consulte também [ARQUIVOS].

--local

Para as opções de escrita: escreva no arquivo do repositório .git/config. 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

Semelhante a opção --local, exceto que o a opção de configuração .git/config.worktree é lido ou gravado caso extensions.worktreeConfig existir. Caso não seja, é o mesmo que a opção --local.

-f arquivo-config

--file arquivo-config

Utilize o arquivo de configuração informado em vez daquele especificado por GIT_CONFIG.

--blob blob

É semelhante a opção --file porém utilize a bolha informada em vez de um arquivo. Como por exemplo, é possível utilizar master:.gitmodules para ler os valores de um arquivo .gitmodules no ramo "master". Para conhecer uma lista completa das diferentes maneiras de soletrar os nomes das bolhas, consulte a seção "DEFININDO AS REVISÕES" em gitrevisions[7].

--remove-section

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

--rename-section

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

--unset

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

--unset-all

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

-l

--list

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

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

Indetermine o tipo do especificador definido anteriormente (caso tenha sido definido anteriormente). Esta opção solicita que o comando git config não canonize a variável recuperada. A opção --no-type não tem qualquer 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, como 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 (local, global, system, command).

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

Encontre a configuração das cores para nome (por exemplo, color.diff) e gere true ou false. O stdout-is-tty deve ser true ou false e é levado em consideração quando a configuração diz "auto". Caso stdout-is-tty esteja ausente, verifique a saída padrão do próprio comando e encerre com a condição 0 caso a cor deva ser utilizada, ou caso contrário, encerre com a condição 1. Quando a configuração das cores para nome for indefinida, o comando retroage e em vez disso usa color.ui.

--get-color nome [default]

Localize a cor configurada para nome (color.diff.new por exemplo) e gere a sequência no padrão ANSI de cor. Em vez disso o parâmetro opcional default é utilizado, caso não haja uma cor configurada para nome.

--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 (como 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 somente é respeitado durante a listagem da configuração, ou seja, ao utilizar a opção --list ou qualquer um dos --get-* que podem retornar diversos resultados. A predefinição é utilizar um pager.

ARQUIVOS

Caso não seja definido de forma explicita com a opção --file, existem quatro arquivos onde o git config irá procurar as opções de configuração:

$(prefixo)/etc/gitconfig: Arquivo de configuração do sistema.
$XDG_CONFIG_HOME/git/config: Segundo arquivo de configuração específico do usuário. Caso $XDG_CONFIG_HOME não esteja definido ou esteja vazio , a opção de configuração $HOME/.config/git/config será utilizada. Qualquer variável com valor único definido neste arquivo será substituída pelo que estiver em ~/.gitconfig. É uma boa ideia não criar este arquivo no caso de você às vezes usar versões mais antigas do Git, pois o suporte para este arquivo foi adicionado recentemente.
~/.gitconfig: Arquivo de configuração específico do usuário. Também chamado de arquivo de configuração "global".
$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.

Caso nenhuma outra opção seja utilizada, todas as opções de leitura irão ler todos estes arquivos que estiverem disponíveis. Caso o arquivo global ou o arquivo de configuração global inteiro não esteja disponível, eles serão ignorados. Caso o arquivo de configuração do repositório não estiver disponível ou legível, o comando git config encerrará com um código de erro diferente de zero. No entanto, em nenhum dos casos será emitida uma mensagem de erro.

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

Você pode substituir os parâmetros da configuração dos parâmetros individuais ao executar qualquer comando git utilizando a opção -c. Para mais detalhes, consulte git[1].

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

Estas regras podem ser substituídas através da linha de comando ou através das variáveis de ambiente. As opções --global, --system e --worktree limitarão o arquivo utilizado ao arquivo global, em todo o sistema ou por árvore de trabalho, respectivamente. A variável de ambiente GIT_CONFIG environment variable has a similar effecttem um efeito similar, porém é possível definir um nome do arquivo caso queira.

VARIÁVEIS DO AMBIENTE

GIT_CONFIG: Pegue a configuração do arquivo informado em vez de .git/config. Usar a opção "--global" força isso para ~/.gitconfig. Usar a opção "--system" força isso para $(prefixo)/etc/gitconfig.
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].

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 pelas porcelanas. 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; \t é lido como` t` e \0 é lido como 0 cabeçalhos da seção por exemplo e 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 \; acento grave 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 incluir um arquivo da configuração de outro condicionalmente setando 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 o diretório .o que o arquivo git seja.

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.

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

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 literais booleanos verdadeiros são yes, on, true, e 1. Além disso, uma variável definida sem = <valor> é tida como verdadeira.
falso: Os falsos literais booleanos são no, off, false, 0 e uma cadeia de caracteres vazios.

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) and white (branco). A primeira cor é o primeiro plano; a segunda é o plano de fundo. Todas as cores básicas exceto normal possuem uma variante brilhante que pode ser definida prefixando a cor com bright, como brightred.

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

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.

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