- SINOPSIS
- DESCRIÇÃO
- OPÇÕES
- COMANDOS GIT
- COMANDOS DE ALTO NÍVEL (PORCELANA)
- COMANDOS DE BAIXO NÍVEL (PLUMBING)
- GUIAS
- REPOSITÓRIO, COMANDOS E INTERFACES DE ARQUIVO
- FORMATOS DE ARQUIVO, PROTOCOLOS E OUTRAS INTERFACES DE DESENVOLVEDOR
- MECANISMO DE CONFIGURAÇÃO
- TERMINOLOGIA DE IDENTIFICADORES
- IDENTIFICADORES SIMBÓLICOS
- ESTRUTURA DE ARQUIVOS/DIRETÓRIOS
- TERMINOLOGIA
- VARIÁVEIS DE AMBIENTE
- DISCUSSÃO
- SEGURANÇA
- DOCUMENTAÇÃO ADICIONAL
- AUTORES
- RELATANDO BUGS
- VEJA TAMBÉM
- GIT
- NOTAS
git - o rastreador de conteúdo estúpido
SINOPSIS
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>]
<comando> [<argumentos>]
DESCRIÇÃO
Git é um sistema de controle de versão distribuído, rápido e escalável, com um conjunto de comandos incomumente rico que fornece operações de alto nível e acesso total aos internos.
Veja gittutorial(7) para começar, depois veja giteveryday(7) para um conjunto mínimo útil de comandos. O Manual do Usuário do Git[1] tem uma introdução mais aprofundada.
Depois de dominar os conceitos básicos, você pode voltar para esta página para aprender quais comandos o Git oferece. Você pode aprender mais sobre comandos individuais do Git com "git help comando". A página de manual gitcli(7) dá a você uma visão geral da sintaxe do comando da linha de comando.
Uma cópia formatada e com hiperlinks 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 conjunto Git da qual o programa git foi obtido.
Esta opção é internamente convertida para git version ... e aceita as mesmas opções do comando git-version(1). Se --help também for fornecido, ele terá precedência sobre --version.
-h, --help
Imprime a sinopse e uma lista dos comandos mais comumente usados. Se a opção --all ou -a for fornecida, todos os comandos disponíveis são impressos. Se um comando Git for nomeado, esta opção exibirá a página de manual para esse comando.
Outras opções estão disponíveis para controlar como a página de manual é exibida. Veja git-help(1) para mais informações, porque git --help ... é internamente convertido em git help ....
-C <path>
Execute como se o git tivesse sido iniciado em
Esta opção afeta as opções que esperam um nome de caminho, como --git-dir e --work-tree, de forma que suas interpretações dos nomes de caminho seriam feitas em relação ao diretório de trabalho causado pela opção -C. 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 <name>=<value>
Passe um parâmetro de configuração para o comando. O valor fornecido substituirá os valores dos
arquivos de configuração. Espera-se que
Observe que omitir o = em git -c foo.bar ... é permitido e define foo.bar para o valor booleano true (assim como [foo]bar faria em um arquivo de configuração). Incluir o sinal de igual, mas com um valor vazio (como em git -c foo.bar= ...) define foo.bar para uma string vazia, que git config --type=bool converterá para false.
`--config-env=<name>=<envvar>`
Semelhante a -c <name\>=<value>, atribui um valor à variável de configuração <name>, onde <envvar> é o nome de uma variável de ambiente da qual obter o valor. Ao contrário de -c, não há um atalho para definir diretamente o valor para uma string vazia; em vez disso, a própria variável de ambiente deve ser definida como uma string vazia. É um erro se <envvar> não existir no ambiente. <envvar> não pode conter um sinal de igual para evitar ambiguidade com <name> contendo um.
Isso é útil em casos onde você deseja passar opções de configuração transitórias para o git, mas está fazendo isso em sistemas operacionais onde outros processos podem ser capazes de ler sua linha de comando (por exemplo, /proc/self/cmdline), mas não seu ambiente (por exemplo, /proc/self/environ). Esse é o comportamento padrão no Linux, mas pode não ser em seu sistema.
Observe que isso pode adicionar segurança para variáveis como http.extraHeader, onde a informação confidencial faz parte do valor, mas não, por exemplo, url.<base>.insteadOf, onde a informação confidencial pode fazer parte da chave.
`--exec-path[=<path>]`
Caminho para onde seus programas principais do Git estão instalados. Isso também pode ser controlado definindo a variável de ambiente GIT_EXEC_PATH. Se nenhum caminho for fornecido, o git imprimirá a configuração atual e, em seguida, sairá.
`--html-path`
Imprime o caminho, sem barra final, onde a documentação HTML do Git está instalada e sai.
`--man-path`
Imprime o caminho man (veja man(1)) para as páginas de manual desta versão do Git e sai.
`--info-path`
Imprime o caminho onde os arquivos Info documentando esta versão do Git estão instalados e sai.
`-p, --paginate`
Envia toda a saída para less (ou, se definido, $PAGER) se a saída padrão for um terminal. Isso substitui as opções de configuração pager.<cmd> (veja a seção "Mecanismo de Configuração" abaixo).
`-P, --no-pager`
Não envia a saída do Git para um paginador.
`--git-dir=<path>`
Define o caminho para o repositório (diretório ".git"). Isso também pode ser controlado definindo a variável de ambiente GIT_DIR. Pode ser um caminho absoluto ou um caminho relativo para o diretório de trabalho atual.
Especificar o local do diretório ".git" usando esta opção (ou a variável de ambiente GIT_DIR) desativa a descoberta do repositório que tenta encontrar um diretório com um subdiretório ".git" (que é como o repositório e o nível superior da árvore de trabalho são descobertos) e diz ao Git que você está no nível superior da árvore de trabalho. Se você não estiver no diretório de nível superior da árvore de trabalho, você deve dizer ao Git onde o nível superior da árvore de trabalho está, com a opção --work-tree=<path> (ou a variável de ambiente GIT_WORK_TREE).
Se você só quer executar o git como se ele tivesse sido iniciado em <path>, use git -C <path>.
--work-tree=<path>
Define 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 (veja core.worktree em gitconfig(1) para uma discussão mais detalhada).
--namespace=<path>
Define o namespace do Git. Veja gitnamespaces(7) para mais detalhes. Equivalente a definir a
variável de ambiente GIT_NAMESPACE.
--bare
Trata o repositório como um repositório bare. Se a variável de ambiente GIT_DIR não estiver definida, ela será definida para o diretório de trabalho atual.
--no-replace-objects
Não use refs de substituição para substituir objetos Git. Isso é equivalente a exportar a
variável de ambiente GIT_NO_REPLACE_OBJECTS com qualquer valor. Veja git-replace(1) para mais
informações.
--no-lazy-fetch
Não busque objetos ausentes do repositório promissor sob demanda. Útil em conjunto com git
cat-file -e <object\> para verificar se o objeto está disponível localmente. Isso é equivalente a definir
a variável de ambiente GIT_NO_LAZY_FETCH para 1.
--no-optional-locks
Não execute operações opcionais que exigem bloqueios. Isso é equivalente a definir GIT_OPTIONAL_LOCKS como 0.
--no-advice
Desabilita todas as dicas de aviso para que não sejam impressas.
--literal-pathspecs
Trata pathspecs literalmente (ou seja, sem globbing, sem mágica de pathspec). Isso é equivalente a definir a
variável de ambiente GIT_LITERAL_PATHSPECS para 1.
--glob-pathspecs
Adiciona mágica "glob" a todos os pathspecs. Isso é equivalente a definir a variável de ambiente GIT_GLOB_PATHSPECS
para 1. Desabilitar o globbing em pathspecs individuais pode ser feito usando a mágica de pathspec ":(literal)".
--noglob-pathspecs
Adiciona mágica "literal" a todos os pathspecs. Isso é equivalente a definir a variável de ambiente GIT_NOGLOB_PATHSPECS
para 1. Habilitar o globbing em pathspecs individuais pode ser feito usando a mágica de pathspec ":(glob)".
--icase-pathspecs
Adiciona mágica "icase" a todos os pathspecs. Isso é equivalente a definir a variável de ambiente GIT_ICASE_PATHSPECS
para 1.
--list-cmds=<group>[,<group>...]
Lista comandos por grupo. Esta é uma opção interna/experimental e pode mudar ou ser removida
no futuro. Grupos suportados são: builtins, parseopt (comandos builtin que usam
parse-options), main (todos os comandos no diretório libexec), others (todos os outros comandos em $PATH
que têm prefixo git-), list-<category> (veja as categorias em command-list.txt), nohelpers
(exclui comandos auxiliares), alias e config (recupera a lista de comandos da variável de configuração
completion.commands).
--attr-source=<tree-ish>
Lê gitattributes de <tree-ish\> em vez da árvore de trabalho. Veja gitattributes(5). Isso é
equivalente a definir a variável de ambiente GIT_ATTR_SOURCE.
COMANDOS GIT
Dividimos o Git em comandos de alto nível ("porcelain") e comandos de baixo nível ("plumbing").
COMANDOS DE ALTO NÍVEL (PORCELANA)
Separamos os comandos de porcelana em comandos principais e alguns utilitários de usuário auxiliares.
Comandos principais de porcelana
git-add(1)
Adiciona o conteúdo dos arquivos ao índice.
git-am(1)
Aplica uma série de patches de uma caixa de correio.
git-archive(1)
Cria um arquivo de arquivos de uma árvore nomeada.
git-backfill(1)
Baixa objetos ausentes em um clone parcial.
git-bisect(1)
Usa busca binária para encontrar o commit que introduziu um bug.
git-branch(1)
Lista, cria ou exclui branches.
git-bundle(1)
Move objetos e refs por meio de um arquivo.
git-checkout(1)
Alterna entre branches ou restaura arquivos da árvore de trabalho.
git-cherry-pick(1)
Aplica as alterações introduzidas por alguns commits existentes.
git-citool(1)
Alternativa gráfica para git-commit.
git-clean(1)
Remove arquivos não rastreados da árvore de trabalho.
git-clone(1)
Clona um repositório em um novo diretório.
git-commit(1)
Registra as alterações no repositório.
git-describe(1)
Dá a um objeto um nome legível por humanos com base em um ref disponível.
git-diff(1)
Mostra as alterações entre commits, commit e árvore de trabalho, etc.
git-fetch(1)
Baixa objetos e refs de outro repositório.
git-format-patch(1)
Prepara patches para envio por e-mail.
git-gc(1)
Limpa arquivos desnecessários e otimiza o repositório local.
git-grep(1)
Imprime linhas que correspondem a um padrão.
git-gui(1)
Uma interface gráfica portátil para Git.
git-init(1)
Cria um repositório Git vazio ou reinicializa um existente.
git-log(1)
Mostra os logs de commit.
git-maintenance(1)
Executa tarefas para otimizar os dados do repositório Git.
git-merge(1)
Junta duas ou mais histórias de desenvolvimento.
git-mv(1)
Move ou renomeia um arquivo, um diretório ou um link simbólico.
git-notes(1)
Adiciona ou inspeciona notas de objetos.
git-pull(1)
Busca de e integra com outro repositório ou um branch local.
git-push(1)
Atualiza os refs remotos juntamente com os objetos associados.
git-range-diff(1)
Compara dois intervalos de commit (por exemplo, duas versões de um branch).
git-rebase(1)
Reaplica commits sobre outra ponta base.
git-reset(1)
Redefine o HEAD atual para o estado especificado.
git-restore(1)
Restaura arquivos da árvore de trabalho.
git-revert(1)
Reverte alguns commits existentes.
git-rm(1)
Remove arquivos da árvore de trabalho e do índice.
git-shortlog(1)
Resume a saída do git log.
git-show(1)
Mostra vários tipos de objetos.
git-sparse-checkout(1)
Reduz sua árvore de trabalho para um subconjunto de arquivos rastreados.
git-stash(1)
Armazena as alterações em um diretório de trabalho sujo.
git-status(1)
Mostra o status da árvore de trabalho.
git-submodule(1)
Inicializa, atualiza ou inspeciona submódulos.
git-switch(1)
Alterna entre branches.
git-tag(1)
Cria, lista, exclui ou verifica um objeto de tag assinado com GPG.
git-worktree(1)
Gerencia várias árvores de trabalho.
gitk(1)
O navegador do repositório Git.
scalar(1)
Uma ferramenta para gerenciar repositórios Git grandes.
Comandos auxiliares
Manipuladores:
git-config(1)
Obtém e define opções de repositório ou globais.
git-fast-export(1)
Exportador de dados Git.
git-fast-import(1)
Backend para importadores de dados Git de alta velocidade.
git-filter-branch(1)
Reescreve branches.
git-mergetool(1)
Executa ferramentas de resolução de conflitos de mesclagem para resolver conflitos de mesclagem.
git-pack-refs(1)
Empacota cabeçalhos e tags para acesso eficiente ao repositório.
git-prune(1)
Remove todos os objetos inatingíveis do banco de dados de objetos.
git-reflog(1)
Gerencia informações de reflog.
git-refs(1)
Acesso de baixo nível a refs.
git-remote(1)
Gerencia o conjunto de repositórios rastreados.
git-repack(1)
Empacota objetos não empacotados em um repositório.
git-replace(1)
Cria, lista e exclui refs para substituir objetos.
Interrogadores:
git-annotate(1)
Anota linhas de arquivo com informações de commit.
git-blame(1)
Mostra qual revisão e autor modificaram pela última vez cada linha de um arquivo.
git-bugreport(1)
Coleta informações para que o usuário registre um relatório de bug.
git-count-objects(1)
Conta o número de objetos não empacotados e seu consumo de disco.
git-diagnose(1)
Gera um arquivo zip de informações de diagnóstico.
git-difftool(1)
Mostra as alterações usando ferramentas de diff comuns.
git-fsck(1)
Verifica a conectividade e a validade dos objetos no banco de dados.
git-help(1)
Exibe informações de ajuda sobre o Git.
git-instaweb(1)
Navegue instantaneamente pelo seu repositório de trabalho no gitweb.
git-merge-tree(1)
Realiza a mesclagem sem tocar no índice ou na árvore de trabalho.
git-rerere(1)
Reutiliza a resolução gravada de mesclagens conflitantes.
git-show-branch(1)
Mostra branches e seus commits.
git-verify-commit(1)
Verifica a assinatura GPG dos commits.
git-verify-tag(1)
Verifica a assinatura GPG das tags.
git-version(1)
Exibe informações de versão sobre o Git.
git-whatchanged(1)
Mostra logs com as diferenças que cada commit introduz.
gitweb(1)
Interface web Git (front-end web para repositórios Git).
Interagindo com outros
Esses comandos são para interagir com SCMs externos e com outras pessoas por meio de patches enviados por e-mail.
git-archimport(1)
Importa um repositório GNU Arch para o Git.
git-cvsexportcommit(1)
Exporta um único commit para um checkout CVS.
git-cvsimport(1)
Recupera seus dados de outro SCM que as pessoas adoram odiar.
git-cvsserver(1)
Um emulador de servidor CVS para Git.
git-imap-send(1)
Envia uma coleção de patches do stdin para uma pasta IMAP.
git-p4(1)
Importa de e envia para repositórios Perforce.
git-quiltimport(1)
Aplica um conjunto de patches Quilt no branch atual.
git-request-pull(1)
Gera um resumo das alterações pendentes.
git-send-email(1)
Envia uma coleção de patches como e-mails.
git-svn(1)
Operação bidirecional entre um repositório Subversion e o Git.
Reset, restaurar e reverter
Existem três comandos com nomes semelhantes: git reset, git restore e git revert.
git-revert(1) tem como objetivo criar um novo commit que reverte as alterações feitas por outros commits.
git-restore(1) tem como objetivo restaurar arquivos na árvore de trabalho, seja do índice ou de outro
commit. Este comando não atualiza seu branch. O comando também pode ser usado para restaurar
arquivos no índice de outro commit.
git-reset(1) tem como objetivo atualizar seu branch, movendo a ponta para adicionar ou remover commits
do branch. Esta operação altera o histórico de commits.
git reset também pode ser usado para restaurar o índice, sobrepondo-se ao git restore.
COMANDOS DE BAIXO NÍVEL (PLUMBING)
Embora o Git inclua sua própria camada de "porcelana", seus comandos de baixo nível são suficientes para suportar o desenvolvimento de "porcelanas" alternativas. Os desenvolvedores de tais "porcelanas" podem começar lendo sobre 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 é projetada para ser muito mais estável do que os comandos de nível de "porcelana", porque esses comandos são principalmente para uso em scripts. A interface dos comandos de "porcelana", por outro lado, está sujeita a alterações a fim de melhorar a experiência do usuário final.
A seguinte descrição divide os comandos de baixo nível em comandos que manipulam objetos (no repositório, índice e árvore de trabalho), comandos que interrogam e comparam objetos e comandos que movem objetos e referências entre repositórios.
Comandos de manipulação
git-apply(1)
Aplica um patch a arquivos e/ou ao índice.
git-checkout-index(1)
Copia arquivos do índice para a árvore de trabalho.
git-commit-graph(1)
Escreve e verifica arquivos git-commit-graph.
git-commit-tree(1)
Cria um novo objeto de commit.
git-hash-object(1)
Calcula o ID do objeto e, opcionalmente, cria um objeto a partir de um arquivo.
git-index-pack(1)
Cria um arquivo de índice de pacote para um arquivo de pacote existente.
git-merge-file(1)
Executa uma mesclagem de arquivo de três vias.
git-merge-index(1)
Executa uma mesclagem para arquivos que precisam ser mesclados.
git-mktag(1)
Cria um objeto de tag com validação extra.
git-mktree(1)
Cria um objeto de árvore a partir do texto formatado em ls-tree.
git-multi-pack-index(1)
Escreve e verifica multi-pack-indexes.
git-pack-objects(1)
Cria um arquivo de pacote de objetos.
git-prune-packed(1)
Remove objetos extras que já estão em arquivos de pacote.
git-read-tree(1)
Lê informações de árvore no índice.
git-replay(1)
EXPERIMENTAL: Repõe commits em uma nova base, funciona também com repositórios "bare".
git-symbolic-ref(1)
Lê, modifica e exclui referências simbólicas.
git-unpack-objects(1)
Descompacta objetos de um arquivo de pacote.
git-update-index(1)
Registra o conteúdo do arquivo na árvore de trabalho no índice.
git-update-ref(1)
Atualiza o nome do objeto armazenado em uma referência com segurança.
git-write-tree(1)
Cria um objeto de árvore a partir do índice atual.
Comandos de Interrogação
git-cat-file(1)
Fornece conteúdo ou detalhes de objetos de repositório.
git-cherry(1)
Encontra commits que ainda não foram aplicados ao "upstream".
git-diff-files(1)
Compara arquivos na árvore de trabalho e no índice.
git-diff-index(1)
Compara uma árvore com a árvore de trabalho ou o índice.
git-diff-pairs(1)
Compara o conteúdo e o modo de pares de blobs fornecidos.
git-diff-tree(1)
Compara o conteúdo e o modo de blobs encontrados por meio de dois objetos de árvore.
git-for-each-ref(1)
Emite informações sobre cada ref.
git-for-each-repo(1)
Executa um comando Git em uma lista de repositórios.
git-get-tar-commit-id(1)
Extrai o ID do commit de um arquivo criado usando git-archive.
git-ls-files(1)
Mostra informações sobre arquivos no índice e na árvore de trabalho.
git-ls-remote(1)
Lista as referências em um repositório remoto.
git-ls-tree(1)
Lista o conteúdo de um objeto de árvore.
git-merge-base(1)
Encontra os melhores ancestrais comuns possíveis para uma mesclagem.
git-name-rev(1)
Encontra nomes simbólicos para revisões específicas.
git-pack-redundant(1)
Encontra arquivos de pacote redundantes.
git-rev-list(1)
Lista objetos de commit em ordem cronológica inversa.
git-rev-parse(1)
Extrai e manipula parâmetros.
git-show-index(1)
Mostra o índice de arquivo compactado.
git-show-ref(1)
Lista as referências em um repositório local.
git-unpack-file(1)
Cria um arquivo temporário com o conteúdo de um blob.
git-var(1)
Mostra uma variável lógica do Git.
git-verify-pack(1)
Valida arquivos de arquivo Git compactados.
Em geral, os comandos de interrogação não modificam os arquivos na árvore de trabalho.
Sincronizando repositórios
git-daemon(1)
Um servidor muito simples para repositórios Git.
git-fetch-pack(1)
Recebe objetos ausentes de outro repositório.
git-http-backend(1)
Implementação do lado do servidor do Git sobre HTTP.
git-send-pack(1)
Envia objetos através do protocolo Git para outro repositório.
git-update-server-info(1)
Atualiza o arquivo de informações auxiliares para ajudar servidores "dumb".
Os seguintes são comandos auxiliares usados pelos comandos acima; os usuários finais normalmente não os usam diretamente.
git-http-fetch(1)
Faz download de um repositório Git remoto via HTTP.
git-http-push(1)
Envia objetos através de HTTP/DAV para outro repositório.
git-receive-pack(1)
Recebe o que é enviado para o repositório.
git-shell(1)
Shell de login restrito para acesso SSH somente para Git.
git-upload-archive(1)
Envia o arquivo de volta para git-archive.
git-upload-pack(1)
Envia objetos compactados de volta para git-fetch-pack.
Comandos auxiliares internos
Estes são comandos auxiliares internos usados por outros comandos; os usuários finais normalmente não os usam diretamente.
git-check-attr(1)
Mostra informações do gitattributes.
git-check-ignore(1)
Depura arquivos gitignore / exclude.
git-check-mailmap(1)
Mostra nomes e endereços de e-mail canônicos de contatos.
git-check-ref-format(1)
Garante que um nome de referência seja bem formado.
git-column(1)
Mostra dados em colunas.
git-credential(1)
Recupera e armazena credenciais de usuário.
git-credential-cache(1)
Auxiliar para armazenar temporariamente senhas na memória.
git-credential-store(1)
Auxiliar para armazenar credenciais em disco.
git-fmt-merge-msg(1)
Produz uma mensagem de commit de mesclagem.
git-hook(1)
Executa ganchos Git.
git-interpret-trailers(1)
Adiciona ou analisa informações estruturadas em mensagens de commit.
git-mailinfo(1)
Extrai patch e informações de autoria de uma única mensagem de e-mail.
git-mailsplit(1)
Programa simples de divisão de mbox do UNIX.
git-merge-one-file(1)
O programa auxiliar padrão a ser usado com git-merge-index.
git-patch-id(1)
Calcula um ID exclusivo para um patch.
git-sh-i18n(1)
Código de configuração de i18n do Git para scripts shell.
git-sh-setup(1)
Código de configuração comum do shell Git.
git-stripspace(1)
Remove espaços em branco desnecessários.
GUIAS
As seguintes páginas de documentação são guias sobre conceitos do Git.
gitcore-tutorial(7)
Um tutorial básico do Git para desenvolvedores.
gitcredentials(7)
Fornecendo nomes de usuário e senhas ao Git.
gitcvs-migration(7)
Git para usuários do CVS.
gitdiffcore(7)
Ajustando a saída do diff.
giteveryday(7)
Um conjunto mínimo de comandos úteis para o Git do dia a dia.
gitfaq(7)
Perguntas frequentes sobre o uso do Git.
gitglossary(7)
Um glossário do Git.
gitnamespaces(7)
Espaços de nomes do Git.
gitremote-helpers(7)
Programas auxiliares para interagir com repositórios remotos.
gitsubmodules(7)
Montando um repositório dentro de outro.
gittutorial(7)
Uma introdução tutorial ao Git.
gittutorial-2(7)
Uma introdução tutorial ao Git: parte dois.
gitworkflows(7)
Uma visão geral dos fluxos de trabalho recomendados com o Git.
REPOSITÓRIO, COMANDOS E INTERFACES DE ARQUIVO
Esta documentação discute interfaces de repositório e comando 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 atributos por caminho.
gitcli(7)
Interface de linha de comando e convenções do Git.
githooks(5)
Hooks usados pelo Git.
gitignore(5)
Especifica arquivos intencionalmente não rastreados para serem ignorados.
gitmailmap(5)
Mapeia nomes e/ou endereços de e-mail do autor/remetente.
gitmodules(5)
Definindo propriedades do submódulo.
gitrepository-layout(5)
Layout do Repositório Git.
gitrevisions(7)
Especificando revisões e intervalos para o Git.
FORMATOS DE ARQUIVO, PROTOCOLOS E OUTRAS INTERFACES DE DESENVOLVEDOR
Esta documentação discute formatos de arquivo, protocolos de comunicação e outras interfaces de desenvolvedor do Git. Consulte --developer-interfaces em git-help(1).
gitformat-bundle(5)
O formato de arquivo bundle.
gitformat-chunk(5)
Formatos de arquivo baseados em blocos.
gitformat-commit-graph(5)
Formato de grafo de commits do Git.
gitformat-index(5)
Formato do índice do Git.
gitformat-pack(5)
Formato do pacote 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 HTTP baseados em Git.
gitprotocol-pack(5)
Como os pacotes são transferidos pela rede.
gitprotocol-v2(5)
Protocolo de comunicação do Git, 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. Um arquivo de configuração pode ter a seguinte aparência:
#
# Um caractere '#' ou ';' indica um comentário.
#
; variáveis principais
[core]
; Não confie nos modos de arquivo
filemode = false
; identidade do usuário
[user]
name = "Junio C Hamano"
email = "_"
Vários comandos leem do arquivo de configuração e ajustam sua operação de acordo. Consulte git-config(1) para obter uma lista e mais detalhes sobre o mecanismo de configuração.
TERMINOLOGIA DE IDENTIFICADORES
<object>
Indica o nome do objeto para qualquer tipo de objeto.
<blob>
Indica o nome do objeto blob.
<tree>
Indica o nome do objeto árvore.
<commit>
Indica o nome do objeto commit.
<tree-ish>
Indica um objeto árvore, commit ou tag. Um comando que aceita um argumento <tree-ish>
em última análise, deseja operar em um objeto <tree>, mas desreferencia automaticamente os objetos <commit> e
<tag> que apontam para um <tree>.
<commit-ish>
Indica o nome de um objeto de commit ou tag. Um comando que aceita um argumento
<type>
Indica que um tipo de objeto é necessário. Atualmente, um de: blob, tree, commit ou tag.
<file>
Indica um nome de arquivo – quase sempre relativo à raiz da estrutura de árvore GIT_INDEX_FILE descreve.
IDENTIFICADORES SIMBÓLICOS
Qualquer comando Git que aceite qualquer <object> também pode usar a seguinte notação simbólica:
HEAD
indica o cabeçalho do branch atual.
<tag>
um nome de tag válido (ou seja, uma referência refs/tags/<tag>).
<head>
um nome de cabeçalho válido (ou seja, uma referência refs/heads/<head>).
Para obter uma lista mais completa de maneiras de especificar nomes de objetos, consulte a seção "ESPECIFICANDO REVISÕES" em gitrevisions(7).
ESTRUTURA DE ARQUIVOS/DIRETÓRIOS
Consulte o documento gitrepository-layout(5).
Leia githooks(5) para obter mais detalhes sobre cada hook.
SCMs de nível superior podem fornecer e gerenciar informações adicionais em $GIT_DIR.
TERMINOLOGIA
Consulte gitglossary(7).
VARIÁVEIS DE AMBIENTE
Vários comandos Git dão atenção às variáveis de ambiente e alteram seu comportamento. As variáveis de ambiente marcadas como "Boolean" recebem seus valores da mesma forma que as variáveis de configuração booleanas, ou seja, "true", "yes", "on" e números positivos são considerados "yes", enquanto "false", "no", "off" e "0" são considerados "no".
Aqui estão as variáveis:
Sistema
HOME
Especifica o caminho para o diretório pessoal do usuário. No Windows, se não estiver definido, o Git definirá uma variável de ambiente de processo igual a: $HOMEDRIVE$HOMEPATH se ambos $HOMEDRIVE e $HOMEPATH existirem; caso contrário, $USERPROFILE se $USERPROFILE existir.
O Repositório Git
Essas variáveis de ambiente se aplicam a todos os comandos principais do Git. Observação: vale a pena notar que elas podem ser usadas/substituídas por SCMs que estão acima do Git, portanto, tenha cuidado ao usar uma interface frontal estrangeira.
GIT_INDEX_FILE
Esta variável de ambiente especifica um arquivo de índice alternativo. Se não for especificado, o padrão de $GIT_DIR/index é usado.
GIT_INDEX_VERSION
Esta variável de ambiente especifica qual versão do índice é usada ao gravar o arquivo de índice . Não afetará os arquivos de índice existentes. Por padrão, a versão 2 ou 3 do arquivo de índice é usada. Veja git-update-index(1) para mais informações.
GIT_OBJECT_DIRECTORY
Se o diretório de armazenamento de objetos for especificado por meio desta variável de ambiente, os diretórios sha1 serão criados abaixo - caso contrário, o diretório padrão $GIT_DIR/objects é usado.
GIT_ALTERNATE_OBJECT_DIRECTORIES
Devido à natureza imutável dos objetos Git, objetos antigos podem ser arquivados em diretórios compartilhados e somente leitura. Esta variável especifica uma lista separada por ":" (no Windows separada por ";") de diretórios de objetos Git que podem ser usados para pesquisar objetos Git. Novos objetos não serão gravados nesses diretórios.
Entradas que começam com " (aspas duplas) serão interpretadas como caminhos no estilo C com aspas, removendo as aspas duplas iniciais e finais e respeitando as sequências de escape de barra invertida. Por exemplo, o valor "path-with-\"-and-:-in-it":vanilla-path possui dois caminhos: path-with-"-and-:-in-it e vanilla-path.
GIT_DIR
Se a variável de ambiente GIT_DIR estiver definida, ela especifica um caminho a ser usado em vez do .git padrão para a base do repositório. A opção de linha de comando --git-dir também define esse valor.
GIT_WORK_TREE
Define 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
Define o namespace do Git; consulte gitnamespaces(7) para obter detalhes. A opção de linha de comando --namespace também define esse valor.
GIT_CEILING_DIRECTORIES
Deve ser uma lista separada por dois pontos de caminhos absolutos. Se definida, é uma lista de diretórios nos quais o Git não deve entrar (chdir) enquanto procura um diretório de repositório (útil para excluir diretórios de rede de carregamento lento). 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 as entradas nesta lista e resolver quaisquer links simbólicos que possam estar presentes, a fim de compará-los com o diretório atual. No entanto, se mesmo este 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 resolvidos; por exemplo, GIT_CEILING_DIRECTORIES=/maybe/symlink::/very/slow/non/symlink.
GIT_DISCOVERY_ACROSS_FILESYSTEM
Quando executado em um diretório que não possui um diretório de repositório ".git", o Git tenta encontrar um diretório desse tipo nos diretórios pai para encontrar o topo da árvore de trabalho, mas, por padrão, não atravessa as fronteiras do sistema de arquivos. Esta variável booleana pode ser definida como true para informar ao Git para não parar nas fronteiras do sistema de arquivos. Semelhante a GIT_CEILING_DIRECTORIES, isso não afetará um diretório de repositório explícito definido por meio de GIT_DIR ou na linha de comando.
GIT_COMMON_DIR
Se esta variável estiver definida para um caminho, os arquivos que não são da árvore de trabalho e que normalmente estão em $GIT_DIR serão obtidos deste caminho, em vez disso. Os arquivos específicos da árvore de trabalho, como HEAD ou o índice, são obtidos de $GIT_DIR. Consulte gitrepository-layout(5) e git-worktree(1) para obter detalhes. Esta variável tem precedência menor do que outras variáveis de caminho, como GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY...
GIT_DEFAULT_HASH
Se esta variável estiver definida, o algoritmo de hash padrão para novos repositórios será definido para este valor. Este valor é ignorado durante a clonagem e a configuração do repositório remoto é sempre usada. O padrão é "sha1". Consulte --object-format em git-init(1).
GIT_DEFAULT_REF_FORMAT
Se esta variável estiver definida, o formato de back-end de referência padrão para novos repositórios será definido para este valor. O padrão é "files". Consulte --ref-format em git-init(1).
Commits do Git
GIT_AUTHOR_NAME
O nome legível por humanos usado na identidade do autor ao criar objetos de commit ou tag, ou ao gravar reflogs. Substitui as configurações user.name e author.name.
GIT_AUTHOR_EMAIL
O endereço de e-mail usado na identidade do autor ao criar objetos de commit ou tag, ou ao escrever reflogs. Substitui as configurações user.email e author.email.
GIT_AUTHOR_DATE
A data usada para a identidade do autor ao criar objetos de commit ou tag, ou ao escrever reflogs. Consulte git-commit(1) para formatos válidos.
GIT_COMMITTER_NAME
O nome legível por humanos usado na identidade do committer ao criar objetos de commit ou tag, ou ao escrever reflogs. Substitui as configurações user.name e committer.name.
GIT_COMMITTER_EMAIL
O endereço de e-mail usado na identidade do committer ao criar objetos de commit ou tag, ou ao escrever reflogs. Substitui as configurações user.email e committer.email.
GIT_COMMITTER_DATE
A data usada para a identidade do committer ao criar objetos de commit ou tag, ou ao escrever reflogs. Consulte git-commit(1) para formatos válidos.
EMAIL
O endereço de e-mail usado nas identidades de autor e committer se nenhuma outra variável de ambiente ou configuração relevante tiver sido definida.
Diferenças do Git
GIT_DIFF_OPTS
A única configuração válida é "--unified=?" ou "-u=?" para definir o número de linhas de contexto exibidas quando uma diferença unificada é criada. Isso tem precedência sobre qualquer opção "-U" ou "--unified" passada na linha de comando git diff.
GIT_EXTERNAL_DIFF
Quando a variável de ambiente GIT_EXTERNAL_DIFF é definida, o programa especificado por ela é chamado para gerar diferenças, e o Git não usa seu mecanismo de diferença interno. Para um caminho que é adicionado, removido ou modificado, GIT_EXTERNAL_DIFF é chamado com 7 parâmetros:
path old-file old-hex old-mode new-file new-hex new-mode
onde:
<old|new>-file
são arquivos que `GIT_EXTERNAL_DIFF` pode usar para ler o conteúdo de <old|new>,
<old|new>-hex
são os hashes SHA-1 de 40 dígitos,
<old|new>-mode
são a representação octal dos modos de arquivo.
Os parâmetros de arquivo podem apontar para o arquivo de trabalho do usuário (por exemplo, new-file em "git-diff-files"), /dev/null (por exemplo, old-file quando um novo arquivo é adicionado) ou um arquivo temporário (por exemplo, old-file no índice). GIT_EXTERNAL_DIFF não deve se preocupar em remover o arquivo temporário — ele é removido quando GIT_EXTERNAL_DIFF é encerrado.
Para um caminho que não foi mesclado, GIT_EXTERNAL_DIFF é chamado com 1 parâmetro,
Para cada caminho para o qual GIT_EXTERNAL_DIFF é chamado, duas variáveis de ambiente, GIT_DIFF_PATH_COUNTER e GIT_DIFF_PATH_TOTAL, são definidas.
GIT_EXTERNAL_DIFF_TRUST_EXIT_CODE
Se esta variável de ambiente booleana for definida como true, então o comando GIT_EXTERNAL_DIFF deve retornar o código de saída 0 se ele considerar que os arquivos de entrada são iguais ou 1 se ele considerar que são diferentes, como diff(1). Se for definido como false, que é o padrão, então o comando deve retornar o código de saída 0, independentemente da igualdade. Qualquer outro código de saída faz com que o Git relate um erro fatal.
GIT_DIFF_PATH_COUNTER
Um contador baseado em 1, incrementado em um para cada caminho.
GIT_DIFF_PATH_TOTAL
O número total de caminhos.
other
GIT_MERGE_VERBOSITY
Um número que controla a quantidade de saída exibida pela estratégia de mesclagem recursiva. Substitui merge.verbosity. Consulte git-merge(1).
GIT_PAGER
Esta variável de ambiente substitui $PAGER. Se estiver definida como uma string vazia ou com o valor "cat", o Git não iniciará um paginador. Consulte também a opção core.pager em git-config(1).
GIT_PROGRESS_DELAY
Um número que controla quantos segundos de atraso antes de exibir indicadores de progresso opcionais. O padrão é 2.
GIT_EDITOR
Esta variável de ambiente substitui $EDITOR e $VISUAL. É usada por vários comandos Git quando, em modo interativo, um editor precisa ser iniciado. Consulte também git-var(1) e a opção core.editor em git-config(1).
GIT_SEQUENCE_EDITOR
Esta variável de ambiente substitui o editor Git configurado ao editar a lista de tarefas de uma rebase interativa. Consulte também git-rebase(1) e a opção sequence.editor em gitconfig(1).
GIT_SSH, GIT_SSH_COMMAND
Se alguma dessas variáveis de ambiente estiver definida, os comandos git fetch e git push usarão o comando especificado em vez de ssh quando precisarem se conectar a um sistema remoto. Os parâmetros de linha de comando passados para o comando configurado são determinados pela variante ssh. Consulte a opção ssh.variant em git-config(1) para obter detalhes.
$GIT_SSH_COMMAND tem precedência sobre $GIT_SSH e é interpretado pelo shell, o que permite incluir argumentos adicionais. $GIT_SSH, por outro lado, deve ser apenas o caminho para um programa (que pode ser um script shell de wrapper, se argumentos adicionais forem necessários).
Normalmente, é mais fácil configurar quaisquer opções desejadas por meio do arquivo .ssh/config pessoal. Consulte a documentação do ssh para obter mais detalhes.
GIT_SSH_VARIANT
Se esta variável de ambiente estiver definida, ela substituirá a detecção automática do Git se GIT_SSH/GIT_SSH_COMMAND/core.sshCommand se referem ao OpenSSH, plink ou tortoiseplink. Esta variável substitui a configuração ssh.variant que tem o mesmo propósito.
GIT_SSL_NO_VERIFY
Definir e exportar esta variável de ambiente para qualquer valor diz ao Git para não verificar o certificado SSL ao buscar ou enviar por HTTPS.
GIT_ATTR_SOURCE
Define o treeish a partir do qual gitattributes será lido.
GIT_ASKPASS
Se esta variável de ambiente estiver definida, os comandos Git que precisam adquirir senhas ou frases-chave (por exemplo, para autenticação HTTP ou IMAP) chamarão este programa com um prompt adequado como argumento de linha de comando e lerão a senha de sua saída padrão. Consulte também a opção core.askPass em git-config(1).
GIT_TERMINAL_PROMPT
Se esta variável de ambiente booleana estiver definida como falso, o Git não solicitará no terminal (por exemplo, ao solicitar autenticação HTTP).
GIT_CONFIG_GLOBAL, GIT_CONFIG_SYSTEM
Obtenha a configuração dos arquivos fornecidos em vez dos arquivos de configuração global ou de nível de sistema. Se GIT_CONFIG_SYSTEM estiver definido, o arquivo de configuração do sistema definido no momento da compilação (geralmente /etc/gitconfig) não será lido. Da mesma forma, se GIT_CONFIG_GLOBAL estiver 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
Determina se deve ignorar a leitura das configurações do arquivo de configuração global $(prefix)/etc/gitconfig. Esta variável de ambiente booleana pode ser usada juntamente com $HOME e $XDG_CONFIG_HOME para criar um ambiente previsível para um script exigente, ou você pode defini-la como verdadeira para evitar temporariamente o uso de um arquivo /etc/gitconfig defeituoso enquanto aguarda que alguém com permissões suficientes o corrija.
GIT_FLUSH
Se esta variável de ambiente booleana estiver definida como verdadeira, os comandos como git blame (no modo incremental), git rev-list, git log, git check-attr e git check-ignore forçarão um despejo do fluxo de saída após cada registro ter sido despejado. Se esta variável estiver definida como falsa, a saída desses comandos será feita usando E/S completamente armazenada em buffer. Se esta variável de ambiente não estiver definida, o Git escolherá o despejo em buffer ou orientado para registros com base em se stdout parece estar redirecionado para um arquivo ou não.
GIT_TRACE
Habilita mensagens de rastreamento gerais, por exemplo, expansão de alias, execução de comandos internos e execução de comandos externos.
Se esta variável estiver definida como "1", "2" ou "true" (a comparação não diferencia maiúsculas de minúsculas), as mensagens de rastreamento serão impressas em stderr.
Se a variável estiver definida como 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 rastreamento neste descritor de arquivo.
Alternativamente, se a variável estiver 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.
Desdefinir a variável ou defini-la como vazia, "0" ou "false" (sem diferenciar maiúsculas de minúsculas) desabilita as mensagens de rastreamento.
GIT_TRACE_FSMONITOR
Habilita mensagens de rastreamento para a extensão do monitor do sistema de arquivos. Consulte GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_PACK_ACCESS
Habilita mensagens de rastreamento para todos os acessos a quaisquer pacotes. Para cada acesso, o nome do arquivo do pacote e um deslocamento no pacote são registrados. Isso pode ser útil para solucionar alguns problemas de desempenho relacionados a pacotes. Consulte GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_PACKET
Habilita 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 outros problemas de protocolo. O rastreamento é desativado em um pacote que começa com "PACK" (mas veja GIT_TRACE_PACKFILE abaixo). Consulte GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_PACKFILE
Habilita o rastreamento de arquivos de pacote enviados ou recebidos por um determinado programa. Ao contrário de outras saídas de rastreamento, este rastreamento é literal: sem cabeçalhos e sem citação de dados binários. Você quase certamente desejará direcioná-lo para um arquivo (por exemplo, GIT_TRACE_PACKFILE=/tmp/my.pack) em vez de exibi-lo no terminal ou misturá-lo com outras saídas de rastreamento.
Observe que isso está atualmente implementado apenas para o lado do cliente de clones e fetches.
GIT_TRACE_PERFORMANCE
Habilita mensagens de rastreamento relacionadas ao desempenho, por exemplo, o tempo total de execução de cada comando Git. Veja GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_REFS
Habilita mensagens de rastreamento para operações no banco de dados de referências. Veja GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_SETUP
Habilita mensagens de rastreamento imprimindo o diretório .git, a árvore de trabalho e o diretório de trabalho atual após o Git ter concluído sua fase de configuração. Veja GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_SHALLOW
Habilita mensagens de rastreamento que podem ajudar na depuração da busca/clonagem de repositórios rasos. Veja GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_CURL
Habilita um despejo de rastreamento completo do curl de todos os dados de entrada e saída, incluindo informações descritivas, do protocolo de transporte git. Isso é semelhante a usar curl --trace-ascii na linha de comando. Veja GIT_TRACE para opções de saída de rastreamento disponíveis.
GIT_TRACE_CURL_NO_DATA
Quando um rastreamento curl é habilitado (veja GIT_TRACE_CURL acima), não despeje dados (ou seja, despeje apenas linhas e cabeçalhos de informação).
GIT_TRACE2
Habilita mensagens de rastreamento mais detalhadas da biblioteca "trace2". A saída de GIT_TRACE2 é um formato de texto simples para facilitar a leitura.
Se esta variável for definida como "1", "2" ou "true" (a comparação não diferencia maiúsculas de minúsculas), as mensagens de rastreamento serão impressas em stderr.
Se a variável for definida como 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 rastreamento neste descritor de arquivo.
Alternativamente, 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) nesse diretório, com o nome do último componente do SID e um contador opcional (para evitar colisões de nomes de arquivo).
Além disso, se a variável for definida como af_unix:[
Além disso, definir a variável para vazio, "0" ou "false" (sem diferenciar maiúsculas de minúsculas) desabilita as mensagens de rastreamento.
Veja a documentação do Trace2[2] para obter detalhes completos.
GIT_TRACE2_EVENT
Esta configuração grava um formato baseado em JSON, adequado para interpretação por máquina. Veja GIT_TRACE2 para opções de saída de rastreamento disponíveis e a documentação do Trace2[2] para obter detalhes completos.
GIT_TRACE2_PERF
Além das mensagens baseadas em texto disponíveis em GIT_TRACE2, esta configuração grava um formato baseado em colunas para entender as regiões de aninhamento. Veja GIT_TRACE2 para opções de saída de rastreamento disponíveis e a documentação do Trace2[2] para obter detalhes completos.
GIT_TRACE_REDACT
Por padrão, quando o rastreamento é ativado, o Git oculta os valores de cookies, o cabeçalho "Authorization:", o cabeçalho "Proxy-Authorization:" e os URIs de arquivos de pacote. Defina esta variável de ambiente booleana como falso para evitar esta ocultação.
GIT_NO_REPLACE_OBJECTS
Definir e exportar esta variável de ambiente instrui o Git a ignorar referências de substituição e não substituir os objetos Git.
GIT_LITERAL_PATHSPECS
Definir esta variável de ambiente booleana como verdadeiro fará com que o Git trate todos os pathspecs literalmente, em vez de como padrões glob. Por exemplo, executar GIT_LITERAL_PATHSPECS=1 git log -- '.c' pesquisará commits que tocam no caminho .c, não qualquer caminho que o glob *.c corresponda. Você pode querer isso se estiver fornecendo caminhos literais ao Git (por exemplo, caminhos fornecidos anteriormente por git ls-tree, saída --raw diff, etc.).
GIT_GLOB_PATHSPECS
Definir esta variável de ambiente booleana como verdadeiro fará com que o Git trate todos os pathspecs como padrões glob (também conhecidos como "glob magic").
GIT_NOGLOB_PATHSPECS
Definir esta variável de ambiente booleana como verdadeiro fará com que o Git trate todos os pathspecs como literais (também conhecidos como "literal magic").
GIT_ICASE_PATHSPECS
Definir esta variável de ambiente booleana como verdadeiro fará com que o Git trate todos os pathspecs como diferenciados por maiúsculas e minúsculas.
GIT_NO_LAZY_FETCH
Definir esta variável de ambiente booleana como verdadeiro instrui o Git a não buscar objetos ausentes do repositório promissor sob demanda.
GIT_REFLOG_ACTION
Quando uma referência é atualizada, as entradas do reflog são criadas para rastrear o motivo pelo qual a referência foi atualizada (que normalmente é o nome do comando de nível superior que atualizou a referência), além dos valores antigos e novos da referência. Um comando Porcelain scriptado pode usar a função auxiliar set_reflog_action em git-sh-setup para definir seu nome para esta variável quando for invocado como o comando de nível superior pelo usuário final, para ser registrado no corpo do reflog.
GIT_REF_PARANOIA
Se esta variável de ambiente booleana estiver definida como falso, ignore referências quebradas ou mal nomeadas ao iterar sobre listas de referências. Normalmente, o Git tentará incluir quaisquer referências como essas, o que pode causar algumas operações falharem. Geralmente, é preferível, pois operações potencialmente destrutivas (por exemplo, git-prune(1)) são melhores se abortarem em vez de ignorarem referências quebradas (e, portanto, considerarem o histórico ao qual elas apontam como não valendo a pena salvar). O valor padrão é 1 (ou seja, seja paranóico sobre detectar e abortar todas as operações). Você normalmente não precisará definir isso como 0, mas pode ser útil ao tentar recuperar dados de um repositório corrompido.
GIT_COMMIT_GRAPH_PARANOIA
Ao carregar um objeto de commit do grafo de commit, o Git executa uma verificação de existência do objeto no banco de dados de objetos. Isso é feito para evitar problemas com grafos de commit desatualizados que contêm referências a commits já excluídos, mas tem um custo de desempenho.
O padrão é "falso", o que desabilita o comportamento mencionado acima. Definir isso como "verdadeiro" habilita a verificação de existência para que commits desatualizados nunca sejam retornados do
grafo de commit, com o custo de desempenho.
GIT_ALLOW_PROTOCOL
Se definido como uma lista separada por dois pontos de protocolos, comporta-se como se protocol.allow estivesse definido como never, e cada um dos protocolos listados tivesse protocol.
GIT_PROTOCOL_FROM_USER
Defina esta variável de ambiente booleana como false para impedir que os protocolos usados por fetch/push/clone, que estão configurados no estado do usuário, sejam usados. Isso é útil para restringir a inicialização recursiva de submodules de um repositório não confiável ou para programas que fornecem URLs potencialmente não confiáveis para comandos git. Consulte git-config(1) para obter mais detalhes.
GIT_PROTOCOL
Apenas para uso interno. Usado no handshake do protocolo de rede. Contém uma lista separada por dois pontos de chaves com valores opcionais
Observe que os servidores podem precisar ser configurados para permitir que esta variável seja transmitida por alguns transportes. Ela será propagada automaticamente ao acessar repositórios locais (ou seja, file:// ou um caminho do sistema de arquivos), bem como através do protocolo git://. Para git-over-http, deve funcionar automaticamente na maioria das configurações, mas consulte a discussão em git-httpbackend(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 OpenSSH).
Esta configuração é opcional. Se a variável não for propagada, os clientes retornarão ao protocolo "v0" original (mas podem perder algumas melhorias de desempenho ou recursos). Esta variável afeta atualmente apenas clones e fetches; ainda não é usada para pushes (mas pode ser no futuro).
GIT_OPTIONAL_LOCKS
Se esta variável de ambiente booleana for definida como false, o Git concluirá qualquer operação solicitada sem executar nenhuma operação secundária opcional que exija a obtenção de um bloqueio. Por exemplo, isso impedirá que git status atualize o índice como um efeito colateral. Isso é útil para processos em execução em segundo plano que não desejam causar contenção de bloqueio com outras operações no repositório. O padrão é 1.
GIT_REDIRECT_STDIN, GIT_REDIRECT_STDOUT, GIT_REDIRECT_STDERR
Apenas para Windows: permite redirecionar os manipuladores de entrada/saída/erro padrão para caminhos especificados pelas variáveis de ambiente. Isso é particularmente útil em aplicativos multithread, onde a maneira canônica de passar manipuladores padrão via CreateProcess() não é uma opção porque exigiria que os manipuladores fossem marcados como herdáveis (e, consequentemente, cada processo gerado herdaria eles, possivelmente bloqueando as operações regulares do Git). O caso de uso pretendido é usar pipes nomeados para comunicação (por exemplo, \.\pipe\my-git-stdin-123).
Dois valores especiais são suportados: off simplesmente fechará o manipulador de padrão correspondente e, se GIT_REDIRECT_STDERR for 2>&1, a saída de erro padrão será redirecionada para o mesmo manipulador da saída padrão.
GIT_PRINT_SHA1_ELLIPSIS (obsoleto)
Se definido como sim, imprime uma elipse após um valor SHA-1 (abreviado). Isso afeta as indicações de HEADs destacados (git-checkout(1)) e a saída de diff bruta (git-diff(1)). Imprimir uma elipse nos casos mencionados não é mais considerado adequado e o suporte para isso provavelmente será removido em um futuro próximo (junto com a variável).
GIT_ADVICE
Se definido como 0, desativa todas as mensagens de aviso. Essas mensagens têm como objetivo fornecer dicas aos usuários para ajudá-los a sair de situações problemáticas ou aproveitar novos recursos. Os usuários podem desativar mensagens individuais usando as chaves de configuração advice.*. Essas mensagens podem ser perturbadoras para ferramentas que executam processos Git, portanto, esta variável está disponível para desativar as mensagens. (A opção global --no-advice também está disponível, mas versões antigas do Git podem falhar quando esta opção não é reconhecida. A variável de ambiente será ignorada pelas versões do Git que não a reconhecem.)
DISCUSSÃO
Mais detalhes sobre o seguinte estão disponíveis no capítulo de conceitos Git do manual do usuário[3] e gitcore-tutorial(7).
Um projeto Git normalmente consiste em um diretório de trabalho com um subdiretório ".git" no nível superior. O diretório .git contém, entre outras coisas, um banco de dados de objetos compactado que representa
o histórico completo do projeto, um arquivo "index" que vincula esse histórico ao conteúdo atual
da árvore de trabalho e ponteiros nomeados nesse histórico, como tags e cabeçalhos de branch.
O banco de dados de objetos contém objetos de três tipos principais: blobs, que armazenam dados de arquivo; árvores, que apontam para blobs e outras árvores para construir hierarquias de diretórios; e commits, que cada um referencia uma única árvore e um número de commits 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 pai representa uma etapa imediatamente anterior. Commits com mais de um pai representam fusões de linhas de desenvolvimento independentes.
Todos os objetos são nomeados pelo hash SHA-1 de seu conteúdo, normalmente escrito como uma string de 40 dígitos hexadecimais. Esses nomes são globalmente únicos. Todo o histórico que leva a um commit pode ser comprovado assinando apenas esse commit. Um quarto tipo de objeto, a tag, é fornecido para este fim.
Quando criados pela primeira vez, os objetos são armazenados em arquivos individuais, mas para maior eficiência, podem ser compactados posteriormente em "arquivos compactados".
Ponteiros nomeados chamados refs marcam pontos interessantes no histórico. Um ref pode conter o nome SHA-1 de um objeto ou o nome de outro ref (este último é chamado de "ref simbólico"). Refs com nomes que começam com refs/head/ contêm o nome SHA-1 do commit mais recente (ou "cabeçalho") de um branch em desenvolvimento. Os nomes SHA-1 de tags de interesse são armazenados em refs/tags/. Um ref simbólico chamado HEAD contém o nome do branch atualmente selecionado.
O arquivo de índice é inicializado com uma lista de todos os caminhos e, para cada caminho, um objeto blob e um conjunto de atributos. O objeto blob representa o conteúdo do arquivo no momento do head do branch atual. Os atributos (hora da última modificação, tamanho, etc.) são obtidos do arquivo correspondente na árvore de trabalho. Alterações subsequentes na árvore de trabalho podem ser encontradas comparando esses atributos. O índice pode ser atualizado com 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 "stages") para um determinado caminho. Essas stages são usadas para armazenar as várias versões não mescladas de um arquivo quando uma mesclagem está em andamento.
SEGURANÇA
Algumas opções de configuração e arquivos de hook podem fazer com que o Git execute comandos de shell arbitrários. Como a configuração e os hooks não são copiados usando git clone, geralmente é seguro clonar repositórios remotos com conteúdo não confiável, inspecioná-los com git log e assim por diante.
No entanto, não é seguro executar comandos Git em um diretório .git (ou na árvore de trabalho que o envolve) quando esse diretório .git vem de uma fonte não confiável. Os comandos em sua configuração e hooks são executados da maneira usual.
Por padrão, o Git se recusará a executar quando o repositório pertencer a alguém diferente do usuário que está executando o comando. Consulte a entrada para safe.directory em git-config(1). Embora isso possa ajudar a protegê-lo em um ambiente multiusuário, observe que você também pode adquirir repositórios não confiáveis que são de sua propriedade (por exemplo, se você extrair um arquivo zip ou tarball de uma fonte não confiável). Nesses casos, você precisará "sanitizar" o repositório não confiável primeiro.
Se você tiver um diretório .git não confiável, primeiro clone-o com git clone --no-local para obter uma cópia limpa. O Git restringe o conjunto de opções e hooks que serão executados pelo upload-pack, que lida com o lado do servidor de uma clonagem ou busca, mas tenha cuidado, pois a área de superfície para ataque contra o upload-pack é grande, portanto, isso acarreta algum risco. O mais seguro é servir o repositório como um usuário não privilegiado (seja via git-daemon(1), ssh ou usando outras ferramentas para alterar os IDs do usuário). Consulte a discussão na seção SEGURANÇA de git-upload-pack(1).
DOCUMENTAÇÃO ADICIONAL
Consulte as referências na seção "description" para começar a usar o Git. O seguinte provavelmente contém mais detalhes do que o necessário para um usuário iniciante.
O capítulo sobre conceitos Git do manual do usuário[3] e gitcore-tutorial(7) fornecem introduções à arquitetura subjacente do Git.
Consulte gitworkflows(7) para obter uma visão geral dos fluxos de trabalho recomendados.
Consulte também os documentos howto[4] para obter alguns exemplos úteis.
Os internos são documentados na documentação da API do Git[5].
Os usuários que estão migrando do CVS também podem querer ler gitcvs-migration(7).
AUTORES
O Git foi iniciado por Linus Torvalds e atualmente é mantido por Junio C Hamano. Inúmeras contribuições vieram da lista de discussão do Git <_[6]>. https://openhub.net/p/git/contributors/summary fornece uma lista mais completa de colaboradores.
Se você tiver um clone do próprio git.git, a saída de git-shortlog(1) e git-blame(1) pode mostrar os autores para partes específicas do projeto.
RELATANDO BUGS
Relate bugs à lista de discussão do Git <_[6]> onde o desenvolvimento e a manutenção são principalmente realizados. Você não precisa estar inscrito na lista para enviar uma mensagem lá. Veja o arquivo da lista em https://lore.kernel.org/git para relatórios de bugs anteriores e outras discussões.
Problemas que são relevantes para a segurança devem ser divulgados em particular à lista de discussão de Segurança do Git <_[7]>.
VEJA TAMBÉM
gittutorial(7), gittutorial-2(7), giteveryday(7), gitcvs-migration(7), gitglossary(7), gitcoretutorial(7), gitcli(7), O Manual do Usuário do Git[1], gitworkflows(7)
GIT
Parte do conjunto git(1)
NOTAS
Manual do Usuário do Git
file:///usr/share/doc/git/html/user-manual.html
Documentação do Trace2
file:///usr/share/doc/git/html/technical/api-trace2.html
Capítulo de conceitos do Git do manual do usuário
file:///usr/share/doc/git/html/user-manual.html#git-concepts
howto
file:///usr/share/doc/git/html/howto-index.html
Documentação da API do Git
file:///usr/share/doc/git/html/technical/api-index.html
_
mailto:_
_
mailto:_