Através do mecanismo alternativo, um repositório pode herdar parte do seu banco de dados do objeto vindo de outro banco de dados de objeto, chamado "alternativo".

Um repositório simples normalmente é um diretório diretório apropriadamente denominado com um sufixo .git que não possui uma cópia local averiguada de nenhum dos arquivos sob controle da revisão. Ou seja, todos os arquivos administrativos e de controle do Git que normalmente estariam presentes no subdiretório .git oculto estão diretamente presentes no diretório repository.git, e nenhum outro arquivo está presente e é retirado. Normalmente, os editores dos repositórios públicos disponibilizam repositórios simples.

Um objeto sem tipo, por exemplo, o conteúdo de um arquivo.

Um "ramo" é uma linha de desenvolvimento. O commit mais recente em um ramo é referido como o cume deste ramo. O cume do ramo é referenced por um ramo head, que avança à medida que o desenvolvimento adicional é feito no ramo. Um único Git repositório pode monitorar um número arbitrário de ramos, porém a sua árvore de trabalho está associada apenas a uma delas (o ramo "atual" ou "averiguado") e HEAD aponte para esse ramo.

É obsoleto para: índice.

Uma lista dos objetos onde cada objeto objeto contém uma referência ao seu sucessor (por exemplo, o sucessor de um commit pode ser uma das suas origens).

O BitKeeper/cvsps fala por "commit". Como o Git não armazena as alterações, mas declara, que realmente não faz sentido utilizar o termo "changesets" com o Git.

A ação de atualizar todos ou parte da árvore de trabalho com o objeto da árvore ou bolha vindo do banco de dados do objeto, e atualizando o índice e HEAD caso toda a árvore tenha um ponteiro para um novo ramo.

No jargão SCM, a "escolha seletiva" (cherry pick) significa escolher um subconjunto das alterações de uma série de alterações (em geral, commits) e registrá-las como uma nova série de alterações sobre uma base de código diferente. No Git, isso é executado pelo comando git cherry-pick para extrair a alteração introduzida através de um commit já existente e registrá-lo com base no cume do ramo atual como um novo commit.

Uma árvore de trabalho está limpa, caso corresponda à revisão referenciada pelo cabeçalho atual. Consulte também "dirty".

Como um substantivo: um único ponto no histórico do Git; todo o histórico de um projeto é representado como um conjunto de commits inter-relacionados. A palavra "commit" é frequentemente utilizada pelo Git nos mesmos locais onde outros sistemas para o controle da revisão utilizem as palavras "revision" (revisão) ou "version" (versão). Também utilizado como uma abreviação para um objeto commit.

Um sinônimo de DAG estrutura formada pelos commits no banco de dados dos objetos, referenciada pelas dicas da ramificação, utilizando as suas cadeias de commits vinculados. Essa estrutura é o commit gráfico. O gráfico pode ser representado de outras maneiras, por exemplo, o o arquivo "commit-graph".

O arquivo "commit-graph" (normalmente hifenizado) é uma representação suplementar do commit gráfico que acelera os passos do commit-graph. O arquivo "commit-graph" é armazenado ou no diretório .git/objects/info ou no diretório info de um banco de dados alternativo dos objetos .

Um objeto objeto, que contém as informações sobre uma revisão específica, como origem, de quem fez o commit, o autor, a data e o objeto árvore que corresponde diretório da revisão que foi armazenada.

Um objeto commit ou um objeto que pode perder a referência de forma recursiva para um objeto commit. A seguir estão todos os commit-ishes: um objeto commit, um objeto tag que aponta para um objeto commit, um objeto tag que aponta para um objeto tag que aponta para um objeto commit, etc.

Estruturas de dados e utilitários fundamentais do Git. Expõe apenas as ferramentas limitadas ao gerenciamento de código-fonte.

Gráfico acíclico dirigido. Os objetos commit forma um grafo acíclico direcionado, porque eles têm parentes (direcionados), e o grafo dos objetos commit são acíclicos (não existe cadeia que comece e termine com o mesmo objeto).

Um objeto objeto inacessível que não seja acessível, mesmo a partir dos outros objetos inacessíveis; um objeto pendente não tem referências a ele vinda de nenhuma referência ou objeto no repositório.

Referir-se a um symbolic ref: a ação de acessar o reference apontado por uma referência simbólica. A remoção da referência recursiva envolve a repetição do processo mencionado acima na referência resultante até que uma referência não simbólica seja encontrada.

Normalmente, o HEAD armazena o nome do ramo e os comandos que operam no histórico que o HEAD representa, operam no histórico que leva ao cume do ramo onde o HEAD aponta. No entanto, o Git também permite que você averigue um commit arbitrário que não seja necessariamente o cume de qualquer ramo em particular. O HEAD em tal condição é chamado de "desanexado" (detached).

A lista que você consegue com "ls" :-)

Se diz que uma árvore de trabalho está "suja" caso contenha alterações que não foram feito os commits no ramo atual.

Uma mesclagem má é uma mesclagem que introduz as alterações que não aparecem em nenhuma origem.

Um avanço rápido é um tipo especial de mesclagem, onde você tem uma revisão e está "mesclando" outras alterações do ramo que são descendentes do que você tem. Nesse caso, você não faz um merge commit, mas em vez disso, atualiza apenas o seu ramo para que aponte para a mesma revisão do ramo que você está fazendo a mesclagem. Isso acontecerá frequentemente em um ramo monitorado remotamente de um repositório remoto.

Busque um ramo significa obter o cabeçalho ref de um ramo remoto repositório, para descobrir quais os objetos estão faltando no local banco de dados do objeto e para obtê-los também. Consulte também git-fetch[1].

O Linus Torvalds originalmente projetou o Git para ser um sistema de arquivos no espaço do usuário, ou seja, a infraestrutura para armazenar os arquivos e os diretórios. Isso garantiu a eficiência e a velocidade do Git.

É um sinônimo para repositório (para o pessoal do arch).

Um arquivo simples .git na raiz de uma árvore em funcionamento que aponte para o diretório que seja o repositório real. Consulte git-worktree[1] para saber mais ou git-submodule[1]. Para conhecer a sintaxe, consulte gitrepository-layout[5].

O Grafts permite que duas linhas de desenvolvimento diferentes sejam unidas, registrando informações falsas de ancestralidade para os commits. Dessa forma, é possível fazer o Git fingir que o conjunto de parents um commit tenha é diferente do que foi registrado quando o commit foi criado. Configurado através do arquivo .git/info/grafts.

Em termos do Git, é um sinônimo para nome do objeto.

Um named reference para o commit no topo do ramo. Os HEADS são armazenados em um arquivo no diretório $GIT_DIR/refs/heads/, exceto quando é utilizado um ref empacotado. (Consulte git-pack-refs[1].)

O ramo atual. Com mais detalhes: A sua árvore de trabalho normalmente deriva da condição da referência da árvore através do HEAD. O HEAD é a referência para um dos cabeçalhos no seu repositório, exceto quando utilizar um HEAD desanexado, neste caso, referencia diretamente um commit arbitrário.

É um sinônimo para cabeçalho.

Durante a execução normal dos vários comandos Git, são feitas chamadas para os scripts opcionais que permitem que um desenvolvedor adicione mais funcionalidades ou verificações. Normalmente, os ganchos permitem que um comando seja pré-verificado e potencialmente abortado e permite uma notificação após a conclusão da operação. Os scripts do gancho são encontrados no diretório $GIT_DIR/hooks/ e são ativados simplesmente ao remover o sufixo .sample do nome do arquivo. Nas versões anteriores do Git, era necessário torná-los executáveis.

Uma coleção dos arquivos com as informações das estatísticas, cujo conteúdo é armazenado como objetos. O índice é uma versão armazenada da sua árvore de trabalho. Na verdade, ele também pode conter uma segunda e até terceira versão de uma árvore em funcionamento, que são usadas quando for mesclado.

As informações sobre um determinado arquivo, armazenadas no índice. Uma entrada do índice pode ter a mesclagem removida, caso uma mesclagem seja iniciada, porém ainda não foi concluído (ou seja, caso o índice contenha várias versões deste arquivo).

O desenvolvimento predefinido do ramo. Sempre quando você cria um repositório Git, um ramo chamado "master" é criado e se torna o ramo ativo. Na maioria dos casos, contém o desenvolvimento local, embora isto seja puramente por convenção e não seja necessário.

Como verbo: Para trazer o conteúdo de outro ramo (possivelmente de um repositório externo) para o ramo atual. No caso onde a ramificação mesclada seja de um repositório diferente, primeiro isto é feito ao buscar (fetch) o ramo remoto e depois mesclando o seu resultado no ramo atual. Essa combinação das operações de busca e mesclagem é chamada de captura (pull). A mesclagem é realizada através de um processo automático que identifica as alterações feitas desde que as ramificações divirjam e depois aplique todas estas alterações juntas. Nos casos onde as alterações entrem em conflito, pode ser necessária intervenção manual para concluir a mesclagem.

A unidade de armazenamento no Git. Ele é identificado exclusivamente pelo SHA-1 do seu conteúdo. Consequentemente, um objeto não pode ser alterado.

Armazena o conjunto de "objetos", e um objeto individual é identificado pelos seus nomes dos objetos. Geralmente o objeto reside no $GIT_DIR/objects/.

É um sinônimo para o nome do objeto.

O identificador único para um objeto. O nome do objeto geralmente é representado por uma sequência com 40 caracteres hexadecimais. Também chamado coloquialmente de SHA-1.

Um dos identificadores "commit", "árvore", "tag" ou "bolha" descrevendo o tipo de um objeto.

Para mesclar mais de duas ramificações.

O ato de entrar num branch que ainda não existe (ou seja, um unborn branch). Após essa operação, o commit criado inicialmente se torna um commit sem um ramo principal, iniciando um novo histórico.

O repositório upstream predefinido. A maioria dos projetos possui pelo menos um projeto "upstream" que eles monitoram. A predefinição origin é usada para isso. As atualizações do novo "upstream" serão buscados no ramo monitorado remotamente chamado origin/name-of-upstream-branch, que você pode ver usando o comando git branch -r.

Atualize e adicione apenas os arquivos ao diretório de trabalho porém não os exclua, semelhante a como o comando cp -R atualizaria o conteúdo no diretório de destino. Este é o modo predefinido em checkout ao fazer averiguação dos arquivos vindo do índice ou tree-ish. Por outro lado, o modo sem sobreposição também exclui os arquivos monitorados que não estão presentes na fonte, semelhante ao comando rsync --delete.

Um conjunto de objetos que foram compactados em um arquivo (para economizar espaço ou transmiti-los com eficiência).

A lista de identificadores e das outras informações dos objetos em um pacote, para ajudar no acesso eficiente ao conteúdo de um pacote.

O padrão utilizado para limitar os caminhos nos comandos do Git.

Um objeto commit contém uma lista (possivelmente vazia) dos predecessores lógicos na linha de desenvolvimento, ou seja, as suas origens.

A ação de recursividade perder a referência a objeto tag.

O termo pickaxe refere-se a uma opção para as rotinas diffcore que ajudam a selecionar as alterações que adicionam ou excluem uma determinada string. Com a opção --pickaxe-all, ela pode ser utilizada para visualizar completamente o changeset que introduziu ou removeu, digamos, uma determinada linha de texto. Consulte git-diff[1].

Um nome bonito para núcleo do Git.

Nome bonito para programas e conjunto de programas, dependendo do núcleo do Git, apresentando um acesso de alto nível ao núcleo do Git principal. As porcelanas expõem mais uma interface SCM do que o plumbing.

As refs que são por-worktree em vez de global. Atualmente isto é apresentado apenas como HEAD e qualquer outra refs que inicie com refs/bisect/, mas podem posteriormente, incluir outras refs incomuns.

A ref that has different semantics than normal refs. These refs can be read via normal Git commands, but cannot be written to by commands like git-update-ref[1].

Captura um ramo significa fetch (obter) e merge (mesclar). Consulte também git-pull[1].

Fazer um impulsionamento ao ramo significa pegar a ref do cabeçalho do ramo de um repositório remoto, descobrir se é um ancestral da ref (referência) do cabeçalho local e nesse caso, colocar todos os objetos que são acessíveis com base na ref do cabeçalho local e que estão faltando a partir do repositório remoto, para o banco de dados do objeto que atualiza a ref do cabeçalho remoto. Caso o cabeçalho não seja um ancestral do cabeçalho local, o impulsionamento (push) vai falhar.

Todos os ancestrais de um determinado commit são considerados "reachable" (ou acessíveis) a partir deste commit. De um modo mais geral, um objeto é acessível a partir do outro se pudermos alcançá-lo através de um chain seguido de tags para o que quer que eles marque com uma tag, commits para as suas origens ou árvores, e as árvores para as árvores ou as bolhas que os contém.

Os bitmaps de acessibilidade armazenam informações sobre a acessibilidade de um conjunto de commits selecionados num arquivo de pacotes, ou num índice de multi-pack (MIDX), para acelerar a pesquisa dos objetos. Os bitmaps são armazenados num arquivo ".bitmap". Um repositório pode ter, no máximo, um arquivo bitmap em uso. O arquivo bitmap pode pertencer a um pacote ou ao índice multi-pack do repositório (caso exista).

Para reaplicar uma série de alterações de uma ramo para uma base diferente e redefinir o head dessa ramificação para o resultado.

A name that points to an object name or another ref (the latter is called a symbolic ref). For convenience, a ref can sometimes be abbreviated when used as an argument to a Git command; see gitrevisions[7] for details. Refs are stored in the repository.

Um reflog exibe o "histórico" local de uma ref. Em outras palavras, ele pode informar qual foi a 3ª última revisão neste repositório e qual era a sua condição atual, ontem às 21:14. Para mais detalhes consulte o comando git-reflog[1].

A "refspec" is used by fetch and push to describe the mapping between remote ref and local ref. See git-fetch[1] or git-push[1] for details.

Um repositório que é utilizado para rastrear os mesmo projeto porém reside em um outro lugar. Para se comunicar com ramos remotos, consulte fetch ou push.

Um ref que é utilizado para rastrear as modificações de outro repositório. Normalmente se parece com refs/remotes/foo/bar (indicando que rastreia um ramo com nome bar e um remoto chamado foo), coincide o lado direito do fetch configurado refspec. Um ramo monitorado remotamente não deve conter alterações diretas, tão pouco, ter commits locais.

Uma coleção de refs junto com um banco de dados do objeto contendo todos os objetos que são acessível vindas das refs, possivelmente acompanhados por metadados de um ou mais porcelanas. Um repositório pode compartilhar um banco de dados de objetos com outros repositórios através de mecanismo alternativo.

A ação de corrigir manualmente o que uma falha automática mesclagem deixou para trás.

Um sinônimo de commit (o substantivo).

Para jogar fora parte do desenvolvimento, ou seja, atribuir head a um revisão anterior.

Gerenciamento do código fonte (ferramenta).

"Secure Hash Algorithm 1"; uma função hash de criptográfica. No contexto do Git utilizado como sinônimo de object name.

Em geral um sinônimo para shallow repository porém a frase a torna mais explicita criada ao executar o comando git clone --depth=....

Um repositório repositório raso possui um histórico incompleto da quais commits possui parents dos quais cauterizam (em outras palavras, o Git é informado para fingir que estes commits não possuam origens, ainda que esteja cadastrados no objeto commit). Algumas vezes é útil quando você está interessado apenas no histórico recente de um projeto, ainda que o histórico real registrado no "upstream" seja muito maior. Um repositório raso é criado, ao usar a opção --depth para git-clone[1] e o seu histórico pode ser aprofundado posteriormente com git-fetch[1].

Um objeto é utilizado para armazenar temporariamente o conteúdo de um diretório de trabalho sujo e o seu índice para utilização futura.

Um repositório retém o histórico de um projeto separado dentro de um outro repositório (o último na qual é chamado de superproject).

Um repositório se refere a repositórios de outros projetos em suas próprias árvores de trabalho como submódulo. O superprojeto conhece os nomes dos (mas não mantém cópias de nenhum deles) commits dos objetos que contenham os submódulos.

Uma referência simbólica: em vez de conter o próprio id SHA-1, ele tem o formato ref: refs/some/thing e quando é referenciado, elimina a referência recursivamente a esta referência. HEAD é o exemplo primário de um symref. As referências simbólicas são manipuladas com o comando git-symbolic-ref[1].

Um ref sob refs/tags/ no espaço de nomes que aponte para um objeto arbitrário (em geral uma tag que aponta seja para tag ou um objeto commit). Em contraste de um head, a tag não é atualizada pelo comando commit. Uma tag Git não tem nada a ver com uma tag Lisp (que seria chamada de object type dentro do contexto do Git). Uma tag é normalmente utilizada para marcar um ponto específico na ancestralidade de um commit chain.

Um objeto contendo um ref apontando para outro objeto que pode conter uma mensagem como um objeto commit. Também pode conter uma assinatura (PGP), nesse caso, é chamado de "signed tag object".

Um Git comum ramo que é utilizado por um desenvolvedor para identificar uma linha conceitual de desenvolvimento. Como as ramificações são muito fáceis e baratas, muitas vezes é desejável ter várias ramificações pequenas, cada uma contendo conceitos muito bem definidos ou pequenas alterações incrementais, porém relacionadas.

Entre um árvore de trabalho ou um objeto árvore junto com os objetos dependentes blob e os objetos das árvores (uma representação de uma árvore de trabalho).

Um objeto contendo uma lista de nomes e modos em conjunto com refs associados as sua bolhas e ou objetos da árvore. Um tree é equivalente a um diretório.

Um objeto árvore ou um objeto que pode perder a referência recursivamente num objeto da árvore. Perder um objeto commit retorna o objeto da árvore revisão correspondente ao topo diretório. São todos os tree-ishes: um commit-ish, um objeto da árvore, um objeto tag que aponta para o objeto da árvore, um objeto tag que aponta para o objeto tag que aponta para o objeto árvore, etc.

O HEAD pode apontar para um branch que ainda não existe e que ainda não tem nenhum commit nele, e este ramo é chamado de ramo não nascido (unborn branch). A maneira mais comum de os usuários encontrarem um ramo não nascido é criando novamente um repositório sem clonar de outro lugar. O HEAD apontaria para o ramo principal (main) (ou mestre (master), dependendo da sua configuração) que ainda não nasceu. Além disso, algumas operações podem colocá-lo num ramo não nascido com a opção orphan.

Um índice que contenha índices não mesclados entradas do índice.

Um objeto que não é acessível de um ramo, tag, ou de qualquer outra referência.

É predefinido que o ramo que seja mesclado na árvore em questão (ou no ramo onde uma reconstrução (rebase) seja feita). É configurado através do branch.<nome>.remote e branch.<nome>.merge. Caso o ramo "upstream" de A seja origin/B algumas vezes nós dizemos que "A está monitorando origin/B".

A árvore dos arquivos atualmente averiguados. A árvore de trabalho normalmente contém o conteúdo HEAD do commit da árvore, além de quaisquer alterações locais que você fizer, mas ainda o commit não foi feito.

Um repositório pode ter zero (ou seja, um repositório sem nada), uma ou mais árvores de trabalho anexadas a ele. Uma "árvore de trabalho" consiste em uma "árvore de trabalho" e o repositório dos metadados, a maioria dos quais são compartilhados entre outras árvores de trabalho de um único repositório onde alguns dos quais são mantidos separadamente por árvore de trabalho (o índice HEAD e pseudorefs como MERGE_HEAD, por ref da árvore de trabalho e o arquivo de configuração por árvore de trabalho).