Git 🌙
Português (Brasil) ▾ Topics ▾ Latest version ▾ git last updated in 2.47.0

NOME

git - o monitor estúpido de conteúdo

RESUMO

git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
    [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
    [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
    [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
    [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
    <command> [<args>]

DESCRIÇÃO

O Git é um sistema de controle de revisão distribuído, rápido, escalável e com um conjunto de comandos incomumente rico que oferece operações de alto nível e acesso completo aos seus recursos.

Consulte gittutorial[7] para começar e, em seguida, giteveryday[7] para obter um conjunto mínimo útil de comandos. O O manual do usuário do Git tem uma introdução mais aprofundada.

Após dominar os conceitos básicos, você pode voltar a esta página para saber quais comandos o Git oferece. Você pode saber mais sobre comandos individuais do Git com o comando git help. A página do manual gitcli[7] oferece uma visão geral da sintaxe do comando de linha de comando.

Uma cópia formatada e com hiperlink da documentação mais recente do Git pode ser visualizada em https://git.github.io/htmldocs/git.html ou https://git-scm.com/docs.

OPÇÕES

-v
--version

Imprime a versão do pacote Git exibindo a sua origem.

Esta opção é convertida internamente para git version ... e aceita as mesmas opções que o comando git-version[1]. Se a opção --help também for usada, ela tem precedência sobre a opção --version.

-h
--help

Imprime a sinopse e uma lista dos comandos mais usados. Caso a opção --all ou -a seja usada, todos os comandos disponíveis serão impressos. Caso um comando Git seja informado, esta opção exibirá a página do manual deste comando.

Outras opções estão disponíveis para controlar como a página do manual é exibida. Para mais informações, consulte git-help[1], pois o comando git --help ... é convertido internamente em git help ....

-C <caminho>

Executar como se o git tivesse sido iniciado em <caminho> em vez de no diretório de trabalho atual. Quando várias opções -C são usadas, cada -C <caminho> não absoluto subsequente é interpretado em relação ao -C <caminho> anterior. Se o <caminho> estiver presente, mas vazio, por exemplo, -C "", o diretório de trabalho atual não será alterado.

Esta opção afeta as opções que esperam o nome do caminho, como --git-dir e --work-tree, pois as suas interpretações dos nomes dos caminhos seriam feitas em relação ao diretório de trabalho causado pela opção -C. Como, por exemplo, as seguintes invocações são equivalentes:

git --git-dir=a.git --work-tree=b -C c status
git --git-dir=c/a.git --work-tree=c/b status
-c <nome>=<valor>

Repassa um parâmetro de configuração para o comando. O valor fornecido substituirá os valores dos arquivos de configuração. O <nome> é esperado no mesmo formato listado através do comando git config (subchaves separadas por pontos).

Note que ao omitir = no comando git -c foo.bar ... é permitido e define foo.bar com o valor booleano verdadeiro (assim como`[foo]bar` faria em um arquivo de configuração). Incluindo os iguais, porém com um valor vazio (como git -c foo.bar= ...) define foo.bar para a string vazia que git config --type=bool converterá para false.

--config-env=<nome>=<envvar>

Assim como -c <nome>=<valor>, atribui à variável de configuração <nome> um valor, onde <envvar> é o nome de uma variável de ambiente de onde se obtém o valor. Ao contrário da opção -c, não há atalho para definir diretamente o valor como uma string vazia; em vez disso, a própria variável de ambiente deve ser definida como uma string vazia. Ocorrerá um erro se a <envvar> não existir no ambiente. O <envvar> não pode conter um sinal de igual para evitar ambiguidade com <nome> que contenha um.

Isso é útil para casos onde você deseja passar opções de configuração transitórias para o git, porém está fazendo isso em sistemas operacionais onde outros processos possam ser capazes de ler a sua linha de comando (/proc/self/cmdline por exemplo), mas não o seu ambiente (/proc/self/Environment por exemplo). Este é comportamento normal no Linux, mas pode não estar no seu sistema.

Observe que isso pode adicionar segurança para variáveis como http.extraHeader onde as informações confidenciais fazem parte do valor, mas não url.<base>.insteadOf por exemplo onde as informações confidenciais podem fazer parte da chave.

--exec-path[=<caminho>]

O caminho para o local onde os programas principais do Git estão instalados. Isso também pode ser controlado pela configuração da variável de ambiente GIT_EXEC_PATH. Se nenhum caminho for fornecido, o git imprimirá a configuração atual e encerrará.

--html-path

Imprima o caminho, sem barra, onde a documentação HTML do Git está instalada e encerre.

--man-path

Imprima o manpath (consulte man(1)) para as páginas do manual desta versão do Git e encerre.

--info-path

Imprima o caminho onde os arquivos Info que documentam esta versão do Git estão instalados e encerre.

-p
--paginate

Canalize toda a saída para less (ou, se definido, $PAGER) se a saída predefinida for um terminal. Isso substitui as opções de configuração pager.<cmd> (consulte a seção "Mecanismo de configuração" abaixo).

-P
--no-pager

Não canalize a saída do Git para um pager.

--git-dir=<caminho>

Define o caminho para o repositório (o diretório ".git"). Isso também pode ser controlado pela configuração da variável de ambiente GIT_DIR. Pode ser um caminho absoluto ou relativo ao diretório de trabalho atual.

Especificar o local do diretório .git usando essa opção (ou a variável de ambiente GIT_DIR) desativa a descoberta do repositório que tenta encontrar um diretório com o subdiretório .git (que é como o repositório e o nível superior da árvore de trabalho são descobertos) e informa ao Git que você está no nível mais alto da árvore de trabalho. Se você não estiver no diretório do cume da árvore de trabalho, deverá informar ao Git onde está o nível superior da árvore de trabalho, com a opção --work-tree=<caminho> (ou a variável de ambiente GIT_WORK_TREE)

Caso queira executar o git como se tivesse sido iniciado em <caminho>, utilize git -C <caminho>.

--work-tree=<caminho>

Defina o caminho para a árvore de trabalho. Pode ser um caminho absoluto ou um caminho relativo ao diretório de trabalho atual. Isso também pode ser controlado definindo a variável de ambiente GIT_WORK_TREE e a variável de configuração core.worktree (consulte core.worktree do comando git-config[1] para obter informações mais detalhadas).

--namespace=<caminho>

Define o espaços de nomes do Git. Para mais detalhes consulte gitnamespaces[7]. Equivale a definir a variável de ambiente GIT_NAMESPACE.

--bare

Trate o repositório como um repositório simples. Se o ambiente GIT_DIR não estiver definido, ele será definido como o diretório de trabalho atual.

--no-replace-objects

Do not use replacement refs to replace Git objects. This is equivalent to exporting the GIT_NO_REPLACE_OBJECTS environment variable with any value. See git-replace[1] for more information.

--no-lazy-fetch

Do not fetch missing objects from the promisor remote on demand. Useful together with git cat-file -e <object> to see if the object is locally available. This is equivalent to setting the GIT_NO_LAZY_FETCH environment variable to 1.

--no-optional-locks

Não execute operações opcionais que exijam bloqueios. Isso é equivalente que definir o GIT_OPTIONAL_LOCKS como 0.

--no-advice

Disable all advice hints from being printed.

--literal-pathspecs

Trate os pathpecs literalmente (ou seja, sem globbing, sem truques para o pathpec). Isso é o mesmo que definir a variável de ambiente GIT_LITERAL_PATHSPECS como 1.

--glob-pathspecs

Adicione a magia glob para todos os pathspec. É como definir a variável de ambiente GIT_GLOB_PATHSPECS como 1. A desativação do caractere curinga nos pathspecs individuais podem ser feitos utilizando a mágica do pathspec ": (literal)"

--noglob-pathspecs

Adicione a magia literal a todos os "pathspec". É equivalente a definir a variável de ambiente GIT_NOGLOB_PATHSPECS para 1. A ativação dos caracteres curinga nos "pathspecs" individuais podem ser feitos utilizando a mágica do pathspec ":(glob)"

--icase-pathspecs

Adicione a magia icase em todos os pathspec. É como definir a variável de ambiente GIT_ICASE_PATHSPECS como 1.

--list-cmds=<grupo>[,<grupo>…​]

Liste os comandos por grupo. Essa é uma opção interna/experimental e pode mudar ou ser removido no futuro. Os grupos compatíveis são: builtins, parseopt (comandos internos que utilizam parse-options´), main (todos os comandos no diretório 'libexec), others (todos os outros comandos no $PATH que possuem um prefixo git), list- <categoria> (consulte as categorias no command-list.txt), nohelpers (exclua os comandos auxiliares), alias e config (recupera a lista dos comandos da variável completion.commands)

--attr-source=<tree-ish>

Leia o gitattributes do <tree-ish> em vez da árvore de trabalho. Consulte gitattributes[5]. Isso é equivalente a definir a variável de ambiente GIT_ATTR_SOURCE.

OS COMANDOS DO GIT

Dividimos o Git em comandos de alto nível ("porcelana") e de baixo nível ("encanamento").

Comandos de alto nível (porcelana)

Separamos os comandos porcelana nos comandos principais e em alguns utilitários auxiliares do usuário.

Os principais comandos porcelana

git-add[1]

Adiciona o conteúdo dos arquivos ao índice.

git-am[1]

Aplica uma série de patches vindos de uma caixa de e-mails.

git-archive[1]

Cria um histórico dos arquivos a partir de uma determinada árvore.

git-bisect[1]

Utilize a procura binária para localizar o commit que introduziu um bug.

git-branch[1]

Lista, cria ou exclui os ramos.

git-bundle[1]

Mova os objetos e as refs através do histórico.

git-checkout[1]

Mova os ramos ou restaura os arquivos da árvores de trabalho.

git-cherry-pick[1]

Aplica as mudanças introduzidas por alguns commits já existentes.

git-citool[1]

Uma alternativa gráfica ao git-commit.

git-clean[1]

Remove os arquivos da árvore de trabalho sem monitoramento.

git-clone[1]

Clona um repositório num novo diretório.

git-commit[1]

Grava as alterações para o repositório.

git-describe[1]

Dá a um objeto um nome num formato legível para humanos com base num "ref" disponível.

git-diff[1]

Exiba as alterações entre os commits, o commit, árvore de trabalho, etc.

git-fetch[1]

Faz o download dos objetos e dos refs vindo de outro repositório.

git-format-patch[1]

Prepara os patches para serem enviados por e-mail.

git-gc[1]

Exclui os arquivos desnecessários e otimiza o repositório local.

git-grep[1]

Imprima as linhas que coincidam com um padrão.

git-gui[1]

Uma interface gráfica portátil para o Git.

git-init[1]

Cria um repositório vazio para o Git ou reinicializa um repositório já existente.

git-log[1]

Exibe os registros logs de um commit.

git-maintenance[1]

Executa tarefas para otimizar os dados de um repositório Git.

git-merge[1]

Une dois ou mais históricos de desenvolvimento juntos.

git-mv[1]

Move ou renomeia um arquivo, um diretório ou um link simbólico.

git-notes[1]

Adiciona ou inspeciona as anotações dos objetos.

git-pull[1]

Capture de e o integre com um outro repositório ou num outro ramo local.

git-push[1]

Atualiza os refs remotos através da associação dos objetos.

git-range-diff[1]

Compara os dois intervalos de um commit (duas versões de um ramo por exemplo).

git-rebase[1]

Reaplica os commits no topo do outro cume da base.

git-reset[1]

Redefine o HEAD atual para o para a condição determinada.

git-restore[1]

Restaura as árvores de trabalho.

git-revert[1]

Reverte alguns commits já existentes.

git-rm[1]

Remove os arquivos da árvore de trabalho e do índice.

git-shortlog[1]

Faça um resumo da saída do git log.

git-show[1]

Exiba os vários tipos de objetos.

git-sparse-checkout[1]

Reduz a sua árvore de trabalho para um conjunto de arquivos trasteados.

git-stash[1]

Armazene as alterações num diretório fora do diretório de trabalho.

git-status[1]

Exiba a condição atual da árvore de trabalho.

git-submodule[1]

Inicializa, atualiza ou inspeciona submódulos.

git-switch[1]

Alterna entre os ramos.

git-tag[1]

Cria, lista, exclui ou verifica uma tag do objeto com assinatura GPG.

git-worktree[1]

Manipula as diversas árvores de trabalho.

gitk[1]

O navegador do repositório Git.

scalar[1]

Uma ferramenta para gerenciar grandes repositórios Git.

Comandos Auxiliares

Manipuladores:

git-config[1]

Obtém e define os repositórios ou as opções globais.

git-fast-export[1]

Exportador de dados do Git.

git-fast-import[1]

Estrutura para os importadores de dados rápidos do Git.

git-filter-branch[1]

Reescreve os ramos.

git-mergetool[1]

Executa as ferramentas de resolução problemas para resolver os conflitos de mesclagem.

git-pack-refs[1]

Empacota os cabeçalhos e as tags para um acesso eficiente ao repositório.

git-prune[1]

Corta todos os objetos fora de alcance do banco de dados de objetos.

git-reflog[1]

Gerencia as informações do reflog.

git-refs[1]

Low-level access to refs.

git-remote[1]

Gerencia o conjunto de repositórios monitorados.

git-repack[1]

Empacota os objetos não empacotados num repositório.

git-replace[1]

Cria, lista e exclui os refs para a reposição dos objetos.

Interrogadores:

git-annotate[1]

Anota as linhas com as informações do commit.

git-blame[1]

Exibe quais foram as últimas modificações feitas em cada linha de um arquivo separados pela versão da revisão e do autor da modificação.

git-bugreport[1]

Colete informações para que o usuário envie um relatório de erro.

git-count-objects[1]

Conta a quantidade dos objetos que não foram empacotados e seu consumo no disco.

git-diagnose[1]

Gera um arquivo zip com informações de diagnóstico.

git-difftool[1]

Exibe as mudanças utilizando ferramentas diff tradicionais.

git-fsck[1]

Verifica a conectividade e validade dos objetos num banco de dados.

git-help[1]

Exiba a informação de ajuda sobre o Git.

git-instaweb[1]

Navegue instantaneamente no seu repositório de trabalho com o gitweb.

git-merge-tree[1]

Realiza a mesclagem sem tocar no índice ou na árvore de trabalho.

git-rerere[1]

Reutilize uma resolução gravada das mesclagens conflitantes.

git-show-branch[1]

Exiba os ramos e seus respectivos commits.

git-verify-commit[1]

Verifique a assinatura GPG dos commits.

git-verify-tag[1]

Verifique a assinatura GPG das tags.

git-version[1]

Exiba a informação da versão sobre o Git.

git-whatchanged[1]

Show logs with differences each commit introduces.

gitweb[1]

Interface web do Git (frontend web para os repositórios Git).

Interagindo com os outros

Estes comandos são para interagir com um SCM externo e com as outras pessoas através de patch por e-mail.

git-archimport[1]

Importa um repositório GNU Arch no Git.

git-cvsexportcommit[1]

Exporta um único commit para uma averiguação do CVS.

git-cvsimport[1]

Recupera os seus dados vindos de outros SCM que as pessoas adoram odiar.

git-cvsserver[1]

Um emulador de um servidor CVS para o Git.

git-imap-send[1]

Envia uma coleção de patches da entrada padrão para um diretório IMAP.

git-p4[1]

Importa de e submete aos repositório Perforce.

git-quiltimport[1]

Aplica um conjunto de patches no ramo atual.

git-request-pull[1]

Gera um resumo com as modificações pendentes.

git-send-email[1]

Envia uma coleção de patches como sendo e-mails.

git-svn[1]

Operação bidirecional entre um repositório do Subversion e do Git.

Redefina, restaure e reverta

Existem três comandos com nomes semelhantes: git reset, git restore e o git revert.

  • git-revert[1] trata de fazer um novo commit que reverte as alterações feitas por outros commit.

  • git-restore[1] trata da restauração dos arquivos na árvore de trabalho do índice ou de outro commit. Este comando não atualiza o seu ramo. O comando também pode ser usado para restaurar os arquivos no índice do outro commit.

  • git-reset[1] trata da atualização do seu ramo, movendo o topo para adicionar ou remover os commits do ramo. Esta operação altera o histórico do commit.

    O comando git reset também pode ser usado para restaurar o índice, sobrepondo com git restore.

Comandos de baixo nível (encanamento plumbing)

Embora o Git inclua a sua própria camada de porcelana, os seus comandos de baixo nível são suficientes para dar suporte ao desenvolvimento de porcelanas alternativas. Os desenvolvedores de tais porcelanas podem começar lendo sobre os comando git-update-index[1] e git-read-tree[1].

A interface (entrada, saída, conjunto de opções e a semântica) desses comandos de baixo nível deve ser muito mais estável do que a dos comandos no nível porcelana, porque estes comandos são destinados principalmente para utilização com scripts. A interface dos comandos porcelana, por outro lado, está sujeita a alterações para melhorar a experiência do usuário final.

A descrição a seguir divide os comandos de baixo nível em comandos que manipulam os objetos (no repositório, índice e árvore de trabalho), comandos que interrogam, comparam objetos, comandos que movem objetos e suas referências entre os repositórios.

Comandos de manipulação

git-apply[1]

Aplique um patch nos arquivos e/ou ao índice.

git-checkout-index[1]

Copie os arquivos do índice para a árvore de trabalho.

git-commit-graph[1]

Escreve e verifica os arquivos commit-graph do Git.

git-commit-tree[1]

Cria um novo objeto commit.

git-hash-object[1]

Compute object ID and optionally create an object from a file.

git-index-pack[1]

Constrói um pacote índice do arquivo para um arquivo de pacote já existente.

git-merge-file[1]

Execute a mesclagem de um arquivo de três vias.

git-merge-index[1]

Execute uma mesclagem para os arquivos que precisam ser mesclados.

git-mktag[1]

Cria um objeto tag com validação extra.

git-mktree[1]

Cria uma árvore-objeto de um texto com formatação ls-tree.

git-multi-pack-index[1]

Escreve e verifica os diversos índices dos pacotes.

git-pack-objects[1]

Cria um histórico empacotado dos objetos.

git-prune-packed[1]

Remove os objetos extras que estejam atualmente nos arquivos empacotados.

git-read-tree[1]

Lê a informação da árvore no índice.

git-replay[1]

EXPERIMENTAL: Replay commits on a new base, works with bare repos too.

git-symbolic-ref[1]

Lê, modifica e exclui os refs simbólicos.

git-unpack-objects[1]

Desempacota os objetos de um arquivo empacotado.

git-update-index[1]

Registra o conteúdo de um arquivo na árvore de trabalho para o índice.

git-update-ref[1]

Atualiza o nome do objeto armazenado num "ref" de forma segura.

git-write-tree[1]

Cria um objeto árvore com base no índice atual.

Comandos de interrogação

git-cat-file[1]

Provide contents or details of repository objects.

git-cherry[1]

Procura os commits que ainda serão aplicados ao "upstream".

git-diff-files[1]

Compara os arquivos na árvore de trabalho e no índice.

git-diff-index[1]

Compara uma árvore com o diretório de trabalho ou índice.

git-diff-tree[1]

Compara o conteúdo e o modo das bolhas encontrados através de dois objetos da árvore.

git-for-each-ref[1]

Informação de saída de cada "ref".

git-for-each-repo[1]

Execute um comando Git numa lista de repositórios.

git-get-tar-commit-id[1]

Extrai o ID do commit de um arquivo criado utilizando o git-archive.

git-ls-files[1]

Exiba a informação sobre os arquivos no índice e na árvore de trabalho.

git-ls-remote[1]

Lista as referências num repositório remoto.

git-ls-tree[1]

Lista o conteúdo de uma árvore de objetos.

git-merge-base[1]

Localize os melhores ancestrais possíveis para fazer uma mesclagem.

git-name-rev[1]

Localize os nomes simbólicos para os "revs" que foram informados.

git-pack-redundant[1]

Localiza os arquivos "pack" que forem redundantes.

git-rev-list[1]

Lista os objetos de commit em ordem cronológica reversa.

git-rev-parse[1]

Escolha e modele os parâmetros.

git-show-index[1]

Exiba o índice do arquivo empacotado.

git-show-ref[1]

Lista as referências num repositório local.

git-unpack-file[1]

Cria um arquivo temporário com conteúdos bolha.

git-var[1]

Exiba uma variável lógica local para o Git.

git-verify-pack[1]

Valide os arquivos empacotados do Git.

Em geral, os comandos de interrogação não tocam nos arquivos da árvore de trabalho.

Sincronizando os repositórios

git-daemon[1]

Um servidor realmente simples para os repositórios Git.

git-fetch-pack[1]

Recebe os objetos que faltam de um outro repositório.

git-http-backend[1]

Implementação do lado do servidor do Git através do HTTP.

git-send-pack[1]

impulsiona os objetos sob o protocolo Git de um outro repositório.

git-update-server-info[1]

Atualiza a informação auxiliar sobre o arquivo para ajudar os servidores burros.

A seguir, são apresentados os comandos auxiliares utilizados acima; os usuários finais normalmente não os utilizam diretamente.

git-http-fetch[1]

Faz o download de um repositório remoto Git através do HTTP.

git-http-push[1]

Impulsiona (push) os objetos através do HTTP/DAV para um outro repositório.

git-receive-pack[1]

Receba o que é impulsionado ao repositório.

git-shell[1]

Shell de login restrito para acesso somente com o SSH do Git.

git-upload-archive[1]

Envia um arquivo de volta ao git-archive.

git-upload-pack[1]

Envia os objetos compactados para o git-fetch-pack.

Comandos auxiliares internos

Estes são comandos auxiliares internos usados por outros comandos; os usuários finais normalmente não os utilizam diretamente.

git-check-attr[1]

Exiba a informação do gitattributes.

git-check-ignore[1]

Depure o gitignore / exclua os arquivos.

git-check-mailmap[1]

Exiba os nomes canônicos e os endereços de e-mail dos contatos.

git-check-ref-format[1]

Certifique que um nome de uma referência está bem formado.

git-column[1]

Exiba os dados em colunas.

git-credential[1]

Obtém e guarda as credenciais dos usuários.

git-credential-cache[1]

Auxiliar para armazenar as senhas temporariamente na memória.

git-credential-store[1]

Auxiliar para armazenar as credenciais no disco.

git-fmt-merge-msg[1]

Gera uma mensagem de mesclagem do commit.

git-hook[1]

Executa os ganchos do git.

git-interpret-trailers[1]

Adiciona ou analisa as informações estruturadas nas mensagens do commit.

git-mailinfo[1]

Extrai a correção e o autor de uma única mensagem de e-mail.

git-mailsplit[1]

Programa simples para dividir o mbox UNIX.

git-merge-one-file[1]

O programa assistente predefinido de ajuda para usar com o git-merge-index.

git-patch-id[1]

Compute um ID único para um patch.

git-sh-i18n[1]

Código da configuração do i18n do Git para scripts shell.

git-sh-setup[1]

Código da configuração comum do script shell do Git.

git-stripspace[1]

Remove os espaços desnecessários.

Guias

As páginas da documentação a seguir são os guias sobre os conceitos do Git.

gitcore-tutorial[7]

Um tutorial básico do Git para os desenvolvedores.

gitcredentials[7]

Fornecendo nomes de usuário e as senhas para o Git.

gitcvs-migration[7]

Git para os usuários do CVS.

gitdiffcore[7]

Ajustando a saída diff.

giteveryday[7]

Um conjunto mínimo de comandos úteis para o Everyday Git.

gitfaq[7]

Perguntas frequentes sobre a utilização do Git.

gitglossary[7]

Um Glossário do Git.

gitnamespaces[7]

Espaços de nome do Git.

gitremote-helpers[7]

Os programas auxiliares que interagem com os repositórios remotos.

gitsubmodules[7]

Montando um repositório dentro do outro.

gittutorial[7]

Um tutorial de introdução ao Git.

gittutorial-2[7]

Um tutorial de introdução ao Git: parte dois.

gitworkflows[7]

Uma visão geral das recomendações dos fluxos de trabalho com Git.

As interfaces do repositório, do comando e do arquivo

Esta documentação discute as interfaces do repositório e os comandos com as quais os usuários devem interagir diretamente. Consulte --user-formats em git-help[1] para obter mais detalhes sobre os critérios.

gitattributes[5]

Definindo todos os atributos por caminho.

gitcli[7]

Interface da linha de comando do Git e convenções.

githooks[5]

Ganchos utilizados pelo Git.

gitignore[5]

Especifica quais arquivos intencionalmente não rastreados serão ignorados.

gitmailmap[5]

Mapeie os nomes do autor/de quem fez o commit e/ou os endereços de e-mail.

gitmodules[5]

Definindo as propriedades do submódulo.

gitrepository-layout[5]

O Layout do Repositório Git.

gitrevisions[7]

Determinando as revisões e os intervalor para o Git.

Formatos dos arquivos, protocolos e outras interfaces do desenvolvedor

Esta documentação aborda os formatos dos arquivos, uma abordagem geral dos protocolos e das outras interfaces do desenvolvedor git. Consulte --developer-interfaces em git-help[1].

gitformat-bundle[5]

O formato do arquivo do pacote.

gitformat-chunk[5]

Formatos de arquivo com base em pedaços.

gitformat-commit-graph[5]

Formato git commit-graph.

gitformat-index[5]

Formato git index.

gitformat-pack[5]

Formato pacote do git.

gitformat-signature[5]

Formatos de assinatura criptográfica do Git.

gitprotocol-capabilities[5]

Recursos dos protocolos v0 e v1.

gitprotocol-common[5]

Coisas comuns a vários protocolos.

gitprotocol-http[5]

Protocolos baseados em HTTP do Git.

gitprotocol-pack[5]

Como os pacotes são transferidos via cabo.

gitprotocol-v2[5]

Protocolo Git Wire, versão 2.

Mecanismo de Configuração

O Git usa um formato de texto simples para armazenar personalizações que são por repositório e por usuário. Este arquivo de configuração pode ter a seguinte aparência:

#
# Os caracteres '#' ou ';' indicam um comentário.
#

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

; identidade do usuário
[user]
	name = "Junio C Hamano"
	email = "gitster@pobox.com"

Vários comandos leem o arquivo de configuração e ajustam a sua operação conforme seja necessário. Consulte o comando git-config[1] para obter uma lista e mais detalhes sobre o mecanismo de configuração.

Terminologia do Identificador

<objeto>

Indica o nome do objeto para qualquer tipo de objeto.

<blob>

Indica um nome de um objeto bolha.

<árvore>

Indica um nome de um objeto árvore.

<commit>

Indica um nome de um objeto commit.

<tree-ish>

Indica um nome do objeto da árvore, commit ou as etiquetas. Um comando que recebe um argumento <tree-ish> deseja operar num objeto <´árvore>, mas remove a referência automaticamente nos objetos <commit> e <etiqueta> que apontam para uma <árvore>.

<commit-ish>

Indica um nome da etiqueta do objeto ou do commit. Um comando que recebe um argumento <commit-ish> deseja operar num objeto <commit>, mas remove a referência automaticamente nos objetos <etiqueta> que apontam para um <commit>.

<tipo>

Indica que é necessário um tipo de objeto. Atualmente é um dos seguintes: blob, tree, commit ou tag.

<arquivo>

Indica um nome do arquivo - quase sempre em relação à raiz da estrutura da árvore que o GIT_INDEX_FILE descreve.

Identificadores Simbólicos

Qualquer comando Git que aceite qualquer <objeto> também pode utilizar a seguinte notação simbólica:

HEAD

indica o cabeçalho do ramo atual.

<tag>

uma tag válida nome (por exemplo, uma referência refs/tags/<tag>).

<head>

um cabeçalho válido nome (por exemplo, uma referência refs/heads/<head>).

Para obter uma lista mais completa de maneiras de soletrar os nomes dos objetos, consulte a seção "DEFININDO AS REVISÕES" em gitrevisions[7].

A Estrutura dos Arquivos/Diretórios

Favor consultar o documento gitrepository-layout[5].

Para mais detalhes sobre cada gancho, consulte githooks[5].

Os SCMs de alto nível podem fornecer e gerenciar informações adicionais no $GIT_DIR.

Terminologia

Favor consultar gitglossary[7].

As Variáveis do Ambiente

Vários comandos do Git se atentam às variáveis de ambiente e alteram o seu comportamento. As variáveis de ambiente marcadas como Boolean assumem seus valores da mesma forma que as variáveis de configuração com valor booleano, por exemplo, true, yes, on e números positivos são considerados como yes.

Aqui estão as variáveis:

O Repositório Git

Essas variáveis de ambiente se aplicam a todos os comandos principais do Git. Nb: é importante notar que eles podem ser usados/substituídos pelo SCMS acima do Git, portanto, tenha cuidado caso esteja usando um front-end externo.

GIT_INDEX_FILE

Essa variável de ambiente determina um arquivo alternativo do índice. Caso não seja definido, é utilizado o padrão $GIT_DIR/index.

GIT_INDEX_VERSION

Esta variável de ambiente especifica qual versão do índice é usada ao gravar o arquivo do índice. Isso não afetará os arquivos existentes no índice. É predefinido que seja usada a versão 2 ou 3 do arquivo do índice. Para mais informações consulte git-update-index[1].

GIT_OBJECT_DIRECTORY

Caso o diretório de armazenamento dos objetos seja informado através desta variável de ambiente, os diretórios sha1 serão criados embaixo - caso contrário, o diretório predefinido $GIT_DIR/objects será utilizado.

GIT_ALTERNATE_OBJECT_DIRECTORIES

Devido à natureza imutável dos objetos Git, os objetos antigos podem ser arquivados em diretórios compartilhados com somente leitura apenas. Esta variável especifica uma lista ":" separada (no Windows ";") dos diretórios dos objetos Git que podem ser utilizados para localizar objetos Git. Os novos objetos não serão gravados nestes diretórios.

As entradas que começam com " (aspas duplas) serão interpretadas como caminhos entre as aspas no estilo C, removendo as aspas duplas iniciais e finais, respeitando as escapes da barra invertida. Como por exemplo, o valor "path-with-\"-and-:-in-it":vanilla-path possuí dois caminhos: path-with-"-and-:-in-it e vanilla-path.

GIT_DIR

Se a variável de ambiente GIT_DIR for definida, ela especificará um caminho que será usada para a base do repositório em vez do padrão .git. A opção de linha de comando --git-dir também define este valor.

GIT_WORK_TREE

Defina o caminho para a raiz da árvore de trabalho. Isso também pode ser controlado pela opção de linha de comando --work-tree e pela variável de configuração core.worktree.

GIT_NAMESPACE

Defina o espaços de nomes do Git; para mais detalhes consulte gitnamespaces[7]. A opção de linha de comando --namespace também define este valor.

GIT_CEILING_DIRECTORIES

Essa deve ser uma lista de caminhos absolutos separados por dois-pontos. Se definido, é uma lista de diretórios para os quais o Git não deve fazer um chdir ao procurar pelo diretório do repositório (útil para excluir diretórios de rede com carregamento lento). Ele não excluirá o diretório de trabalho atual ou um GIT_DIR definido na linha de comando ou no ambiente. Normalmente, o Git precisa ler os itens dessa lista e resolver qualquer link simbólico que possa estar presente para compará-los com o diretório atual. No entanto, se mesmo esse acesso for lento, você pode adicionar uma entrada vazia à lista para informar ao Git que as entradas subsequentes não são links simbólicos e não precisam ser resolvidas; por exemplo, GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.

GIT_DISCOVERY_ACROSS_FILESYSTEM

Quando executado num diretório que não tenha um diretório de repositório .git, o Git tenta encontrar esse diretório nos diretórios pai para encontrar o cume da árvore de trabalho, mas, por padrão, ele não cruza os limites do sistema de arquivos. Essa variável de ambiente booleana pode ser definida como true para dizer ao Git para não parar nos limites do sistema de arquivos. Assim como o GIT_CEILING_DIRECTORIES, isso não afetará um diretório de repositório explícito definido via GIT_DIR ou na linha de comando.

GIT_COMMON_DIR

Se essa variável estiver definida para um caminho, os arquivos que não são da árvore de trabalho, estão normalmente estão em $GIT_DIR e serão obtidos desse caminho. Os arquivos específicos da árvore de trabalho, como HEAD ou índice serão obtidos de $GIT_DIR. Para mais detalhes consulte gitrepository-layout[5] e git-worktree[1]. Essa variável tem precedência mais baixa do que outras variáveis de caminho como GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY…​

GIT_DEFAULT_HASH

Se essa variável for definida, o algoritmo de hash predefinido para os novos repositórios será definido com este valor. Esse valor é ignorado durante a clonagem e a configuração do repositório remoto é sempre usada. A predefinição é sha1. Consulte a opção --object-format do comando git-init[1].

GIT_DEFAULT_REF_FORMAT

Se esta variável for definida, o formato padrão do "backend" de referência para os novos repositórios será definido com esse valor. A predefinição é files. Consulte a opção --ref-format do comando git-init[1].

Os Commits do Git

GIT_AUTHOR_NAME

O endereço legível do endereço de e-mail utilizado na identidade do autor ao criar os commits, na tag dos objetos ou ao gravar os reflogs. Substitui as definições de configuração user.name e author.name.

GIT_AUTHOR_EMAIL

O endereço de email utilizado na identidade do autor ao criar os commits, na marcação dos objetos ou ao gravar os reflogs. Substitui as definições da configuração user.email e author.email.

GIT_AUTHOR_DATE

A data utilizada para a identidade do autor ao criar objetos commit ou tags ou quando escrever "reflogs". Para conhecer os formatos válidos, consulte git-commit[1].

GIT_COMMITTER_NAME

O endereço legível do nome utilizado na identidade do autor do commit ao criar os commits, na tag dos objetos ou ao gravar os reflogs. Substitui as definições de configuração user.name e committer.name.

GIT_COMMITTER_EMAIL

O endereço de email utilizado na identidade do autor ao criar os commits, na marcação dos objetos ou ao gravar os reflogs. Overrides the user.email and committer.email configuration settings.

GIT_COMMITTER_DATE

A data utilizada para a identidade de quem fez o commit durante a criação dos objetos as tags do commit ou ao gravar os reflogs. Para mais formatos válidos, consulte git-commit[1].

EMAIL

O endereço de e-mail usado nas identidades do autor e do commit, caso nenhuma outra variável de ambiente ou da configuração relevante tiver sido definida.

Os Diffs do Git

GIT_DIFF_OPTS

A única configuração válida é --unified=?? ou -u?? para definir a quantidade de linhas de contexto exibidas quando um diff unificado for criado. Isso tem precedência sobre qualquer valor da opção -U ou --unified usado na linha de comando do Git diff.

GIT_EXTERNAL_DIFF

Quando a variável de ambiente GIT_EXTERNAL_DIFF é definida, o programa nomeado por ela é invocado para gerar diferenças, e o Git não usa seu mecanismo de diferenças embutido. Para um caminho que for adicionado, removido ou modificado, o GIT_EXTERNAL_DIFF é invocado com 7 parâmetros:

path old-file old-hex old-mode new-file new-hex new-mode

onde:

<old|new>-file

são os arquivos que GIT_EXTERNAL_DIFF pode utilizar para ler o conteúdo do <antigo|novo>,

<old|new>-hex

são os hashes SHA-1 com 40 hexadecimais,

<old|new>-mode

são a representação octais dos modos dos arquivos.

Os parâmetros do arquivo podem apontar para o arquivo de trabalho do usuário (new-file em git-diff-files por exemplo), /dev/null (old-file quando um novo arquivo é adicionado por exemplo) ou um arquivo temporário (old-file no índice por exemplo). O GIT_EXTERNAL_DIFF não deve se preocupar em desvincular o arquivo temporário - ele é removido quando o GIT_EXTERNAL_DIFF for encerrado.

Para um caminho que não foi mesclado, GIT_EXTERNAL_DIFF é chamado com 1 parâmetro, <caminho>.

Para cada caminho GIT_EXTERNAL_DIFF que é chamado, duas variáveis de ambiente,GIT_DIFF_PATH_COUNTER e GIT_DIFF_PATH_TOTAL são definidas.

GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE

If this Boolean environment variable is set to true then the GIT_EXTERNAL_DIFF command is expected to return exit code 0 if it considers the input files to be equal or 1 if it considers them to be different, like diff(1). If it is set to false, which is the default, then the command is expected to return exit code 0 regardless of equality. Any other exit code causes Git to report a fatal error.

GIT_DIFF_PATH_COUNTER

Um contador com base 1 incrementado por um em cada caminho.

GIT_DIFF_PATH_TOTAL

A quantidade total dos caminhos.

Outros

GIT_MERGE_VERBOSITY

Um número que controla a quantidade de saída exibida pela estratégia de mesclagem recursiva. Substitui o merge.verbosity. Consulte o comando git-merge[1]

GIT_PAGER

Esta variável de ambiente substitui a variável $PAGER. Se for definido como uma string vazia ou com o valor cat, o Git não iniciará um gerenciador. Consulte também a opção core.pager do comando git-config[1].

GIT_PROGRESS_DELAY

Um número que controla quantos segundos atrasar antes de mostrar os indicadores opcionais do progresso. A predefinição retorna para 2.

GIT_EDITOR

Essa variável de ambiente substitui $EDITOR e $VISUAL. Ele é usado por vários comandos do Git quando, no modo interativo, um editor tiver que ser iniciado. Consulte também git-var[1] e a opção core.editor do comando git-config[1].

GIT_SEQUENCE_EDITOR

Esta variável de ambiente substitui a configuração do editor do Git ao editar a lista de tarefas de um rebase interativo. Consulte também o comando git-rebase[1] e a opção sequence.editor em git-config[1].

GIT_SSH
GIT_SSH_COMMAND

Se uma dessas variáveis de ambiente estiver definida, o git fetch e o git push usarão o comando especificado em vez do ssh quando precisarem se conectar a um sistema remoto. Os parâmetros da linha de comando passados para o comando configurado são determinados pela variante ssh. Para mais detalhes consulte a opção ssh.variant do comando git-config[1].

O $GIT_SSH_COMMAND tem precedência sobre o $GIT_SSH e é interpretado pelo shell, o que permite a inclusão de argumentos adicionais. O $GIT_SSH, por outro lado, deve ser apenas o caminho para um programa (que pode ser um script de shell de proteção, caso argumentos adicionais sejam necessários).

Normalmente, é mais fácil configurar as opções desejadas através do seu arquivo pessoal .ssh/config. Consulte a documentação do ssh para obter mais informações.

GIT_SSH_VARIANT

Se esta variável de ambiente estiver configurada, ela substitui a detecção automática do Git, caso GIT_SSH/GIT_SSH_COMMAND/core.sshCommand se refere ao OpenSSH, plink ou tortoiseplink. Esta variável substitui a configuração ssh.variant que serve ao mesmo propósito.

GIT_SSL_NO_VERIFY

Ao definir e exportar essa variável de ambiente para qualquer valor, informa ao Git para não verificar o certificado SSL ao buscar ou enviar via HTTPS.

GIT_ATTR_SOURCE

Define a árvore da qual os gitattributes serão lidos.

GIT_ASKPASS

Se essa variável de ambiente for definida, os comandos do Git que precisarem obter senhas ou frases-senha (por exemplo, para autenticação HTTP ou IMAP) invocarão este programa com um prompt adequado como argumento de linha de comando e lerão a senha de seu STDOUT. Consulte também a opção core.askPass do comando git-config[1].

GIT_TERMINAL_PROMPT

Caso esta variável de ambiente boleana esteja definida como false, o git não será solicitado no terminal (ao solicitar uma autenticação HTTP por exemplo).

GIT_CONFIG_GLOBAL
GIT_CONFIG_SYSTEM

Obtenha a configuração dos arquivos fornecidos em vez dos arquivos de configuração globais ou em nível de sistema. Se o GIT_CONFIG_SYSTEM for definido, o arquivo de configuração do sistema definido no momento da compilação (geralmente /etc/gitconfig) não será lido. Da mesma maneira, se o GIT_CONFIG_GLOBAL for definido, nem $HOME/.gitconfig nem $XDG_CONFIG_HOME/git/config serão lidos. Pode ser definido como /dev/null para ignorar a leitura de arquivos de configuração do respectivo nível.

GIT_CONFIG_NOSYSTEM

Se deve ignorar a leitura das configurações do arquivo $(prefix)/etc/gitconfig de todo o sistema. Esta variável de ambiente booleana pode ser usada junto com $HOME e $XDG_CONFIG_HOME para criar um ambiente previsível para um script mais exigente, ou você pode defini-la como verdadeira para evitar temporariamente o uso de um arquivo /etc/gitconfig com erros enquanto espera que alguém com permissões suficientes o conserte.

GIT_FLUSH

Se essa variável de ambiente booleana for definida como true, comandos como git blame (no modo incremental), git rev-list, git log, git check-attr e git check-ignore irão impor uma descarga do fluxo de saída após cada registro ter sido descarregado. Se essa variável for definida como false, a saída desses comandos será feita usando a E/S que estiver armazenada no buffer. Se esta variável de ambiente não for definida, o Git escolherá a descarga com o buffer ou orientada a registros com base no fato do stdout parecer estar sendo redirecionado para um arquivo ou não.

GIT_TRACE

Ativa o rastreio geral das mensagens, por exemplo expansão do pseudônimo, execução interna dos comandos e a execução externa dos comandos.

Caso esta variável esteja definida como 1, 2 ou true (a comparação não diferencia as maiúsculas das minúsculas), as mensagens de rastreio serão impressas no stderr.

Caso a variável seja configurada com um valor inteiro maior que 2 e menor que 10 (estritamente), o Git interpretará este valor como um descritor de arquivo aberto e tentará gravar as mensagens de monitoramento neste descritor do arquivo.

Como alternativa, caso a variável estiver definida como um caminho absoluto (começando com um caractere /), o Git interpretará isso como um caminho do arquivo e tentará anexar as mensagens de rastreio nelas.

Desativar a variável ou defini-la como vazia 0 ou false (não faz distinção entre maiúsculas e minúsculas) desativa as mensagens de monitoramento.

GIT_TRACE_FSMONITOR

Ativa as mensagens de rastreamento para a extensão do monitor de arquivos do sistema. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_PACK_ACCESS

Ativa as mensagens de rastreamento para todos os acessos a qualquer pacote. Para cada acesso, são registrados o nome do arquivo do pacote e o offset. Isso pode ser útil para solucionar alguns problemas de desempenho relacionados ao pacote. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_PACKET

Ativa as mensagens de rastreamento para todos os pacotes que entram ou saem de um determinado programa. Isso pode ajudar a depurar a negociação de objetos ou de outros problemas de protocolo. O rastreamento é desativado num pacote que começa com "PACK" (consulte o GIT_TRACE_PACKFILE abaixo). Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_PACKFILE

Permite o monitoramento dos arquivos dos pacotes enviados ou recebidos através de um determinado programa. Diferente de outras saídas monitoradas, esse monitoramento é literalmente: sem cabeçalhos e sem a citação dos dados binários. Você quase que certamente vai querer direcionar para um arquivo (GIT_TRACE_PACKFILE=/tmp/my.pack por exemplo) em vez de exibi-lo no terminal ou misturá-lo com uma outra saída monitorada.

Observe que atualmente isso é implementado apenas para o lado do cliente dos clones e das buscas.

GIT_TRACE_PERFORMANCE

Ativa as mensagens de rastreamento relacionadas ao desempenho, como o tempo total de execução de cada comando do Git por exemplo. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_REFS

Ativa as mensagens de rastreamento para as operações no banco de dados de referência. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_SETUP

Permite que as mensagens de rastreamento imprimam o .git, a árvore de trabalho e o diretório de trabalho atual depois que o Git tiver concluído a sua fase de configuração. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_SHALLOW

Ativa asmensagens de rastreamento que possam ajudar a depurar a busca/clonagem dos repositórios rasos. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_CURL

Ativa um curl que faz um dump de rastreamento completo de todos os dados da entrada e da saída, incluindo informações descritivas, do protocolo de transporte git. Isso é semelhante a fazer curl --trace-ascii na linha de comando. Consulte o GIT_TRACE para consultar as opções de rastreamento disponíveis.

GIT_TRACE_CURL_NO_DATA

Quando um rastreamento curl está ativado (consulte GIT_TRACE_CURL acima), não despeje os dados (ou seja, apenas despeje as linhas de informações e os cabeçalhos).

GIT_TRACE2

Ativa as mensagens de rastreamento mais detalhadas da biblioteca "trace2". A saída do GIT_TRACE2 é um formato simples com base em texto para facilitar a leitura humana.

Caso esta variável esteja definida como 1, 2 ou true (a comparação não diferencia as maiúsculas das minúsculas), as mensagens de rastreio serão impressas no stderr.

Caso a variável seja configurada com um valor inteiro maior que 2 e menor que 10 (estritamente), o Git interpretará este valor como um descritor de arquivo aberto e tentará gravar as mensagens de monitoramento neste descritor do arquivo.

Como alternativa, se a variável for definida como um caminho absoluto (começando com um caractere /), o Git interpretará isso como um caminho de arquivo e tentará anexar as mensagens de rastreamento a ele. Se o caminho já existir e for um diretório, as mensagens de rastreamento serão gravadas em arquivos (um por processo) neste diretório, nomeados de acordo com o último componente do SID e um contador opcional (para evitar colisões de nomes de arquivos).

Além disso, se a variável for definida como af_unix:[<tipo-do-soquete>:]<nome-do-caminho-completo>, o Git tentará abrir o caminho como um Unix Domain Socket. O tipo de soquete pode ser stream ou dgram.

Desativar a variável ou defini-la como vazia 0 ou false (não faz distinção entre maiúsculas e minúsculas) desativa as mensagens de monitoramento.

Para mais detalhes, consulte Trace2 documentation.

GIT_TRACE2_EVENT

Esta configuração grava um formato baseado em JSON que é adequado para interpretação por máquina. Consulte GIT_TRACE2 para obter as opções disponíveis de saída do rastreamento e Documentação do Trace2 para consultar todos os detalhes.

GIT_TRACE2_PERF

Além das mensagens com base em texto disponíveis no GIT_TRACE2, esta configuração grava um formato baseado em colunas para entender as regiões de aninhamento. Consulte GIT_TRACE2 para obter as opções disponíveis de saída do rastreamento e Documentação do Trace2 para consultar todos os detalhes.

GIT_TRACE_REDACT

É predefinido que quando o monitoramento seja ativado, o Git redita os valores dos cookies, o cabeçalho "Autorização:" o cabeçalho e o URI do arquivo do pacote "Autorização do proxy:". Defina esta variável de ambiente boleana como false para evitar esta redação.

GIT_NO_REPLACE_OBJECTS

Setting and exporting this environment variable tells Git to ignore replacement refs and do not replace Git objects.

GIT_LITERAL_PATHSPECS

Ao definir essa variável de ambiente boleana como true fará com que o Git trate todos os pathspecs de forma literal, e não como padrões glob. Como, por exemplo, a execução do GIT_LITERAL_PATHSPECS=1 git log -- '*.c' procurará pelos commits que tocam no caminho *.c e não nos caminhos que coincidem com o agrupamento *.c. Você pode querer isso caso esteja alimentando caminhos literais para o Git (por exemplo, os caminhos informados anteriormente a você pelo git ls-tree, --raw, saída do diff, etc).

GIT_GLOB_PATHSPECS

Ao definir essa variável de ambiente boleana como true fará com que o Git trate todos os pathspecs como padrões "glob" (também informados como "glob" mágico).

GIT_NOGLOB_PATHSPECS

Ao definir essa variável de ambiente boleana como true fará com que o Git trate todos os pathspecs como literal (também informados como mágica "literal").

GIT_ICASE_PATHSPECS

Ao definir essa variável de ambiente boleana como true fará com que o Git trate todos os pathspecs como indiferente para maiúsculas e minúsculas.

GIT_NO_LAZY_FETCH

Setting this Boolean environment variable to true tells Git not to lazily fetch missing objects from the promisor remote on demand.

GIT_REFLOG_ACTION

Quando uma ref é atualizada, são criadas entradas de reflog para manter o controle do motivo pelo qual a ref foi atualizada (que normalmente é o nome do comando de alto nível que atualizou a ref), além dos valores antigos e novos da ref. Um comando porcelana com script pode usar a função auxiliar set_reflog_action no git-sh-setup para definir seu nome para essa variável quando for invocado como o comando de nível superior pelo usuário final, a ser registrado no corpo do reflog.

GIT_REF_PARANOIA

Caso essa variável de ambiente boleana seja definida como false, ignore os refs quebrados ou mal nomeados ao iterar sobre as listas dos refs. Normalmente o Git tentará incluir qualquer um desses refs, o que pode causar a falha de algumas operações. Isto normalmente é preferível, já que as operações potencialmente destrutivas (como git-prune[1]) são melhores abortando em vez de ignorar os refs quebrados (e assim considerando o histórico que eles apontam como não valendo a pena salvar). O valor predefinido é true (ou seja, ser paranoico ao detectar e abortar todas as operações). Normalmente não é preciso definir isso como false, mas pode ser útil ao tentar salvar os dados de um repositório corrompido.

GIT_COMMIT_GRAPH_PARANOIA

Ao carregar um objeto commit do gráfico do commit-graph, o Git executa uma verificação de existência do objeto no banco de dados. Isso é feito para evitar problemas com commit-graphs obsoletos que contêm referências a commits que já foram excluídos, ao custo de uma penalidade no desempenho.

A predefinição é false, que desativa o comportamento mencionado acima. Ativa a verificação de existência para que os commits que estejam desatualizados nunca sejam retornados do commit-graph, ao custo de uma penalidade no desempenho.

GIT_ALLOW_PROTOCOL

Caso seja definido como uma lista de protocolos separados por dois pontos, comporte-se como se a opção de configuração protocol.allow esteja definida como never, e cada um dos protocolos listados possua protocol.<nome>.allow definido como always (substituindo qualquer configuração já existente). Consulte a descrição do protocol.allow no git-config[1] para obter mais detalhes.

GIT_PROTOCOL_FROM_USER

Defina esta variável booleana de ambiente como false para evitar que os protocolos usados por fetch/push/clone sejam configurados para o estado user. Isso é útil para restringir a inicialização recursiva de submódulos a partir de um repositório não confiável ou para programas que alimentam URLS potencialmente não confiáveis para os comandos do git. Para mais detalhes consulte git-config[1].

GIT_PROTOCOL

For internal use only. Used in handshaking the wire protocol. Contains a colon : separated list of keys with optional values <key>[=<value>]. Presence of unknown keys and values must be ignored.

Observe que os servidores podem precisar ser configurados para permitir que esta variável passe por alguns transportes. Ele será propagado automaticamente ao acessar os repositórios locais (ou seja, file:// ou um caminho do sistema de arquivos), bem como sobre o protocolo git://. Para git-over-http, ele deve funcionar automaticamente na maioria das configurações, porém consulte git-http-backend[1]. Para git-over-ssh, o servidor ssh pode precisar ser configurado para permitir que os clientes passem esta variável (por exemplo, usando AcceptEnv GIT_PROTOCOL com o OpenSSH).

Esta configuração é opcional. Caso a variável não seja propagada, os clientes voltarão ao protocolo "v0" original (mas podem perder algumas melhorias de desempenho ou de recursos). Atualmente esta variável afeta apenas os clones e as buscas (fetch); ainda não é usado para envios "push" (mas pode ser no futuro).

GIT_OPTIONAL_LOCKS

Se essa variável de ambiente booleana for definida como false, o Git concluirá qualquer operação solicitada sem executar nenhuma suboperação opcional que exija um bloqueio. Por exemplo, como um efeito colateral, isso impedirá que o git status atualize o índice. Isso é útil para processos executados em segundo plano que não queiram causar contenção de bloqueio com outras operações no repositório. A predefinição é 1.

GIT_REDIRECT_STDIN
GIT_REDIRECT_STDOUT
GIT_REDIRECT_STDERR

Apenas no Windows: permite redirecionar os identificadores predefinidos de input/output/error para os caminhos definidos através das variáveis do ambiente. Em particular isso é útil nos aplicativos "multi-threaded" onde a maneira canônica de encaminhar os identificadores predefinidos através do CreateProcess() não seja uma opção pois exigiria que os identificadores fossem marcados como herdáveis (e consequentemente todo processo gerado os herdaria, possivelmente fazendo o bloqueio das operações do Git). A intenção primária de utilização é utilizar os pipes informados para comunicação (\\.\pipe\my-git-stdin-123 por exemplo).

Dois valores especiais são compatíveis: off simplesmente fechará o identificador predefinido correspondente e caso GIT_REDIRECT_STDERR seja 2> & 1, a predefinição do erro será redirecionado para o mesmo identificador na saída padrão.

GIT_PRINT_SHA1_ELLIPSIS (descontinuado)

Se definido como yes, imprime uma elipse após um valor SHA-1 (abreviado). Isso afeta as indicações de `HEAD`s desanexados (git-checkout[1]) e a criação de um diff puro (git-diff[1]). A impressão de reticências nos casos mencionados não é mais considerada adequada e o suporte para isso provavelmente será removido num futuro próximo (junto com a variável).

GIT_ADVICE

If set to 0, then disable all advice messages. These messages are intended to provide hints to human users that may help them get out of problematic situations or take advantage of new features. Users can disable individual messages using the advice.* config keys. These messages may be disruptive to tools that execute Git processes, so this variable is available to disable the messages. (The --no-advice global option is also available, but old Git versions may fail when this option is not understood. The environment variable will be ignored by Git versions that do not understand it.)

Discussão

Um projeto Git normalmente consiste num diretório de trabalho com um subdiretório .git no nível mais alto. O diretório .git contém, entre outras coisas, um banco de dados dos objetos compactado que representa o histórico completo do projeto, um arquivo index (índice) que vincula este histórico ao conteúdo atual da árvore de trabalho e os ponteiros nomeados neste histórico, como as etiquetas (tags) e os cabeçalhos da ramificação.

O banco de dados do objeto contém os objetos dos tipos da árvore principal: bolhas, que contêm os dados do arquivo; árvores, que apontam para as bolhas e as outras árvores para criar as hierarquias do diretório; e os commits, cada qual faz referência a uma única árvore e algum número do commit do pai.

O commit, equivalente ao que outros sistemas chamam de conjunto de alterações ou versão, representa uma etapa no histórico do projeto, e cada ramo principal (parent) representa uma etapa imediatamente anterior. Os commits com mais de um ramo principal representam as mesclagens das linhas independentes do desenvolvimento.

Todos os objetos são nomeados pelo hash SHA-1 de seu conteúdo, normalmente escrito como uma cadeia de 40 dígitos hexadecimais. Estes nomes são únicos globalmente. Todo o histórico que leva a um commit pode ser comprovado assinando apenas este commit. Um quarto tipo de objeto, a etiqueta (tag), é fornecida para esta finalidade.

Quando criados pela primeira vez, os objetos são armazenados em arquivos individuais, porém, visando uma maior eficiência, podem ser compactados posteriormente em "pacotes de arquivos".

Os ponteiros mencionados chamados de refs marcam pontos interessantes na história. Uma ref pode conter o nome do SHA-1 de um objeto ou o nome de outra ref (esta última é chamada de "ref simbólica" (symbolic ref)). As refs com nomes que começam com refs/head/ contêm o nome SHA-1 do commit mais recente (ou cabeçalho HEAD) de uma ramificação em desenvolvimento. Os nomes SHA-1 das etiquetas de interesse são armazenados em refs/tags/. Uma ref simbólica denominada HEAD contém o nome do ramo atualmente submetido ao check-out.

O arquivo do índice é inicializado com uma lista de todos os caminhos e, para cada caminho, um objeto bolha (blob) e um conjunto de atributos. O objeto bolha (blob) representa o conteúdo do arquivo a partir do cabeçalho da ramificação atual. Os atributos (hora da última alteração, tamanho, etc.) são obtidos do arquivo correspondente na árvore de trabalho. As alterações subsequentes na árvore de trabalho podem ser encontradas através da comparação destes atributos. O índice pode ser atualizado com um novo conteúdo, e novos commits podem ser criados a partir do conteúdo armazenado no índice.

O índice também é capaz de armazenar várias entradas (chamadas de "stages" ou "estágios") para um determinado nome do caminho. Estes estágios são usados para manter as várias versões não mescladas de um arquivo quando uma mesclagem já estiver em andamento.

SEGURANÇA

Some configuration options and hook files may cause Git to run arbitrary shell commands. Because configuration and hooks are not copied using git clone, it is generally safe to clone remote repositories with untrusted content, inspect them with git log, and so on.

However, it is not safe to run Git commands in a .git directory (or the working tree that surrounds it) when that .git directory itself comes from an untrusted source. The commands in its config and hooks are executed in the usual way.

By default, Git will refuse to run when the repository is owned by someone other than the user running the command. See the entry for safe.directory in git-config[1]. While this can help protect you in a multi-user environment, note that you can also acquire untrusted repositories that are owned by you (for example, if you extract a zip file or tarball from an untrusted source). In such cases, you’d need to "sanitize" the untrusted repository first.

If you have an untrusted .git directory, you should first clone it with git clone --no-local to obtain a clean copy. Git does restrict the set of options and hooks that will be run by upload-pack, which handles the server side of a clone or fetch, but beware that the surface area for attack against upload-pack is large, so this does carry some risk. The safest thing is to serve the repository as an unprivileged user (either via git-daemon[1], ssh, or using other tools to change user ids). See the discussion in the SECURITY section of git-upload-pack[1].

DOCUMENTAÇÃO ADICIONAL

Consulte as referências na seção "descrição" para começar a usar o Git. Os detalhes a seguir provavelmente são maiores do que o necessário para um usuário iniciante.

O capítulo de conceitos do Git do manual do usuário e o gitcore-tutorial[7] fornecem introduções à arquitetura subjacente do Git.

Para obter uma visão geral das recomendações do fluxo de trabalho, consulte gitworkflows[7].

Para mais alguns exemplos úteis, consulte também o documento howto.

As entranhas estão documentadas no Documentação da API do Git.

Os usuários que estiverem migrando do CVS também podem querer ler gitcvs-migration[7].

Autores

O Git foi criado por Linus Torvalds e atualmente é mantido por Junio C Hamano. Várias contribuições vieram da lista de discussão do Git <git@vger.kernel.org>. O site https://openhub.net/p/git/contributors/summary fornece uma lista mais completa dos colaboradores.

Caso tenha um clone do git.git, a saída do git-shortlog[1] e do git-blame[1] pode exibir os autores para as partes específicas do projeto.

Reportando um Erro

Relate os erros na lista de discussão do Git <git@vger.kernel.org>, onde o desenvolvimento principal e a manutenção são feitas. Não é necessário estar inscrito na lista para enviar uma mensagem para lá. Consulte o arquivo da lista em https://lore.kernel.org/git para ver relatórios de erros anteriores além de outras discussões.

Os problemas relevantes para a segurança devem ser divulgadas em particular na mailing list do Git Security <git-security@googlegroups.com>.

GIT

Parte do conjunto git[1]

scroll-to-top