Git
Português (Brasil) ▾Topics ▾Latest version ▾ gitglossary last updated in 2.44.0

NOME

gitglossary - Um Glossário do Git

RESUMO

*

DESCRIÇÃO

alternate object database (banco de dados alternativo do objeto)

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

bare repository (repositório simples)

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.

blob object (objeto bolha)

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

branch (ramo)

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.

cache

É obsoleto para: índice.

chain (cadeia ou corrente)

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

changeset (conjunto de alterações)

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.

checkout (averiguação)

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.

cherry-picking (escolha-seletiva)

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.

clean

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

commit

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.

Como um verbo: A ação de armazenar um novo instantâneo da condição do projeto no histórico do Git, criando um novo commit que representa a condição atual do índice e avançando o HEAD apontando para o novo commit.

conceito do commit gráfico, representações e uso

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

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 .

commit object (objeto commit)

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.

commit-ish (também committish)

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.

core Git (núcleo do Git)

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

DAG

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

dangling object (objeto pendurado, pendente)

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.

dereference

Referring to a symbolic ref: the action of accessing the reference pointed at by a symbolic ref. Recursive dereferencing involves repeating the aforementioned process on the resulting ref until a non-symbolic reference is found.

Referring to a tag object: the action of accessing the object a tag points at. Tags are recursively dereferenced by repeating the operation on the result object until the result has either a specified object type (where applicable) or any non-"tag" object type. A synonym for "recursive dereference" in the context of tags is "peel".

Referring to a commit object: the action of accessing the commit’s tree object. Commits cannot be dereferenced recursively.

Unless otherwise specified, "dereferencing" as it used in the context of Git commands or protocols is implicitly recursive.

HEAD DESANEXADO

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

Observe que os comandos que operam no histórico do ramo atual (por exemplo o git commit para criar um novo histórico sobre ele) ainda funcionam enquanto o HEAD for desanexado. Eles atualizam o HEAD para apontar no topo do histórico atualizado sem afetar nenhum ramo. Os comandos que atualizam ou consultam informações sobre o ramo atual (por exemplo o comando git branch --set-upstream-to que define com qual ramo monitorado remotamente o ramo atual se integra) obviamente não funcionam, pois não há um ramo atual (real) para perguntar sobre esta condição.

directory (diretório)

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

dirty (sujo)

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

evil merge (mesclagem má, mau, ruim)

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

fast-forward (avanço-rápido)

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.

fetch (busca)

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

file system (sistema de arquivo)

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.

Git archive (arquivo Git)

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

gitfile

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

grafts (grafos)

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.

Observe que o mecanismo de enxertos está desatualizado e pode levar a problemas na transferência dos objetos entre os repositórios; para fazer a mesma coisa consulte git-replace[1] para um sistema mais flexível e robusto.

hash

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

head (cabeçalho, cabeça)

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

HEAD (CABEÇALHO, CABEÇA)

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.

head ref (referência do cabeçalho)

É um sinônimo para cabeçalho.

hook (gancho)

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.

index (índice)

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.

index entry (lançamento, entrada do índice)

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

master (mestre)

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.

merge (mesclar, mesclagem, juntar, combinar, misturar, fundir-se, unir, ligar-se)

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.

Como substantivo: a menos que seja um avanço rápido, uma mesclagem bem-sucedida resulta na criação de um novo commit representando o resultado da mesclagem e tendo como parentes as dicas das ramificações. Este commit refere-se ao chamado "merge commit" (commit da mesclagem) ou às vezes, apenas como "mesclagem".

object (objeto)

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

object database (banco de dados do objeto)

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

object identifier (antigo)

É um sinônimo para o nome do objeto.

object name (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.

tipo do objeto

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

octopus (polvo)

Para mesclar mais de duas ramificações.

órfão

The act of getting on a branch that does not exist yet (i.e., an unborn branch). After such an operation, the commit first created becomes a commit without a parent, starting a new history.

origin (origem)

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.

overlay (cobrir, revestir, sobrepor, capa, camada)

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.

pack (pacote)

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

pack index (índice do pacote)

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.

pathspec (a especificação do caminho)

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

Os pathspecs são utilizados na linha de comando, os comando "git ls-files", "git ls-tree", "git add", "git grep", "git diff", "git checkout" e muitos outros para limitar o escopo das operações para algum subconjunto da árvore ou da árvore de trabalho. Consulte a documentação de cada comando para saber se os caminhos são relativos ao diretório atual ou ao nível mais alto. A sintaxe do pathspec é a seguinte:

  • qualquer caminho corresponde a si próprio

  • o pathspec até a última barra representa um prefixo do diretório. O escopo deste pathspec é limitado a esta subárvore.

  • o restante do pathspec é um padrão para o restante do nome do caminho. Os caminhos relativos ao prefixo do diretório serão comparados com este padrão usando fnmatch(3); * e ? em particular podem ser comparados com os separadores dos diretórios.

Como por exemplo, Documentação/*.jpg irá coincidir com todos os arquivos .jpg na subárvore Documentação, incluindo Documentação/capítulo_1/figura_1.jpg.

Um pathspec que começa com dois pontos : tem um significado especial. Na forma abreviada, os dois pontos iniciais : são seguidos por zero ou mais letras da "assinatura mágica" (que opcionalmente são terminadas por outros dois pontos :), o restante é o padrão que será comparado ao caminho. A "assinatura mágica" consiste em símbolos ASCII que não são caracteres alfanuméricos, glob, regex nem caracteres especiais. Os dois pontos opcionais que encerram a "assinatura mágica" podem ser omitidos caso o padrão comece com um caractere que não pertença ao conjunto dos símbolos da "assinatura mágica" e não seja dois pontos.

Na forma longa, os dois pontos iniciais : são seguidos por um parêntese aberto (, uma lista separada por vírgula de zeros ou mais "palavras mágicas" e parênteses próximos ), o restante é o padrão para coincidir contra o caminho.

Um pathspec com apenas dois pontos significa "não há um pathspec". Este formulário não deve ser combinado com um outro pathspec.

top

A palavra mágica top (assinatura mágica: /) faz o padrão da raiz da árvore de trabalho coincidir mesmo quando você está executando o comando de dentro de um subdiretório.

literal

Curingas no padrão como * ou ? são tratados como caracteres literais.

icase

Coincidência indiferente a letras maiúsculas ou minúsculas.

glob

O Git trata o padrão como um "shell glob" adequado para o consumo do fnmatch(3) com a sinalização FNM_PATHNAME: curingas no padrão não corresponderão com o pathname. Por exemplo, "Documentation/*.html" coincide com "Documentation/git.html", mas não com "Documentation/ppc/ppc.html" ou "tools/perf/Documentation/perf.html".

Dois asteriscos consecutivos ("**") nos padrões coincidentes ao pathname completo podem ter um significado especial:

  • Um "**" inicial seguido de uma barra significa que houve coincidência em todos os diretórios. Por exemplo, "**foo" é coincidente ao arquivo ou diretório "foo" em qualquer lugar, o mesmo que o padrão "foo". "**/foo/bar" é coincidente ao arquivo ou diretório "bar" em qualquer lugar que esteja diretamente sob o diretório "foo".

  • Um "/**" à direita corresponde a tudo que estiver dentro. Por exemplo, "abc/**" coincide todos os arquivos dentro do diretório "abc", relativos à localização do arquivo .gitignore, com uma profundidade infinita.

  • Uma barra seguida por dois asteriscos consecutivos e uma barra coincide com zero ou mais diretórios. Por exemplo, "a/**/b" coincide com "a/b", "a/x/b", "a/x/y/b" e assim por diante.

  • Os outros asteriscos consecutivos são considerados inválidos.

    A magica "glob" é incompatível com a mágica literal.

attr

Após o attr:, vem um espaço separado da lista do "attribute requirements" (requisitos dos atributos), todos os quais devem ser atendidos para que o caminho seja considerado uma correspondência; isso é um acréscimo à coincidência usual dos padrões do pathspec. Consulte gitattributes[5].

Cada um dos requisitos de atributo para o caminho assume uma destas formas:

  • "ATTR" requer que o atributo ATTR seja definido.

  • "ATTR" requer que o atributo ATTR não seja definido.

  • "ATTR=VALUE" requer que o atributo ATTR seja definido como a string VALUE.

  • "!ATTR"requer que o atributo` ATTR` não seja especificado.

    Observe que durante a coincidência com um objeto da árvore, os atributos ainda serão obtidos da mesma e não do objeto da árvore especificado.

exclude (excluí)

Depois que um caminho coincida com qualquer pathspec que não foi excluído ele será executado em todos os pathspecs que foram excluídos (assinatura mágica: ! or its synonym ^). Caso coincida, o caminho é ignorado. Quando não há um pathspec não excluído a exclusão é aplicada ao conjunto de resultados como se fosse invocada sem nenhum pathspec.

parent (pai, origem, matriz)

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

peel

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

pickaxe

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

plumbing (encanamento)

Um nome bonito para núcleo do Git.

porcelain (porcelana)

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.

per-worktree ref (referência por árvore de trabalho)

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.

pseudoref (pseudo referência)

Pseudorefs são uma classe de arquivos em $GIT_DIR que se comporta como refs para fins de análise de revisão, no entanto, são tratados especialmente pelo git. Os pseudorefs têm nomes com maiúsculas e sempre começam com uma linha que consiste em SHA-1, seguido por um espaço. Portanto, HEAD não é um pseudoref pois às vezes é um ref simbólico. Opcionalmente eles podem conter alguns dados adicionais. São exemplos MERGE_HEAD e CHERRY_PICK_HEAD. Ao contrário do per-worktree refs, estes arquivos não podem ser refs simbólicos e nunca possuem um reflogs. Eles também não podem ser atualizados através do mecanismo ref normal de atualização. Em vez disso, eles são atualizados gravando diretamente nos arquivos. No entanto, eles podem ser lidos como se fossem refs, portanto, git rev-parse MERGE_HEAD funcionará.

pull (captura, puxar, atrair, apertar)

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

push (impulsionar, impulso, empurrar, apertar, pressionar, forçar, investida)

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.

reachable (acessível ou alcançável)

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.

bitmaps de alcançabilidade

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

rebase (reconstrução da fundação ou reconstrução)

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.

ref (referência)

Um nome que comece com refs/ (por exemplo, refs/heads/master) que aponte para um object name ou outro ref (o último é chamado de ref simbólica). Por conveniência, uma ref as vezes pode ser abreviado quando utilizado como um argumento em um comando Git; Para mais detalhes consulte gitrevisions[7]. As refs são armazenadas no repositório.

O espaço de nomes da ref é hierárquico. Sub-hierarquias diferentes são utilizadas para diferentes propósitos (por exemplo, a hierarquia refs/heads/ é utilizada para representar as ramificações locais).

Existem algumas referências especiais que não começam com refs/. O exemplo mais notável é HEAD.

reflog

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

refspec

Um refspec é utilizado por fetch e push para descrever o mapeamento entre ref remoto e o ref local.

remote repository (repositório remoto)

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.

remote-tracking branch (monitorando os ramos remotamente)

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.

repository (repositório)

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.

resolve

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

revision (revisão)

Um sinônimo de commit (o substantivo).

rewind (rebobinar, retroceder)

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

SCM

Gerenciamento do código fonte (ferramenta).

SHA-1

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

shallow clone (clonagem superficial)

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

shallow repository (repositório raso)

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

stash entry (lançamento para a armazenagem)

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

ref especial

A ref that has different semantics than normal refs. These refs can be accessed via normal Git commands but may not behave the same as a normal ref in some cases.

As seguintes refs especiais são conhecidas pelo Git:

  • "FETCH_HEAD" is written by git-fetch[1] or git-pull[1]. It may refer to multiple object IDs. Each object ID is annotated with metadata indicating where it was fetched from and its fetch status.

  • "MERGE_HEAD" is written by git-merge[1] when resolving merge conflicts. It contains all commit IDs which are being merged.

submodule (submódulo)

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

superproject (superprojeto)

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.

symref (referência simbólica)

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

tag (etiqueta)

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.

objeto tag (objeto etiqueta, objeto da etiqueta)

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

topic branch (tópico do ramo)

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.

tree (árvore)

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

tree object (objeto árvore)

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.

tree-ish (também treeish)

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.

por nascer

The HEAD can point at a branch that does not yet exist and that does not have any commit on it yet, and such a branch is called an unborn branch. The most typical way users encounter an unborn branch is by creating a repository anew without cloning from elsewhere. The HEAD would point at the main (or master, depending on your configuration) branch that is yet to be born. Also some operations can get you on an unborn branch with their orphan option.

unmerged index (índices não mesclados)

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

unreachable object (objetos inacessíveis)

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

upstream branch (ramo upstream)

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

working tree (árvore de trabalho)

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.

worktree

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

GIT

Parte do conjunto git[1]

scroll-to-top