Longa história curta...

Até onde eu sei, o termo "ramo" (na linguagem Git) pode se referir a coisas relacionadas, mas diferentes:

uma referência / ponteiro não simbólico para um commit,o nome dessa referência (por exemplo, "mestre"),o subgrafo do DAG de confirmação do repositório composto por todos os commits alcançáveis a partir do commit apontado por tal referência.

No entanto, eu já vi o termo usado para se referir a algo diferente daqueles três usos possíveis (mais detalhes abaixo). Em um contexto Git, existem outros usos válidos e inequívocos do termo "ramificação" que minha lista acima está ausente?

Mais detalhes

Depois de usar o Git por cerca de um ano, estou preparando um breve tutorial para estudantes de CS. Eu realmente quero definir a terminologia do Git, para evitar qualquer confusão.

Claro, eu tenho usado os ramos do Git por um tempo agora; Estou confortável em usá-los e acho incrível o modelo de ramificação do Git. No entanto, ainda acho o termo "ramificação" problemático e ambíguo, porque parece se referir a pelo menos duas coisas diferentes, dependendo do contexto em que é usado ... às vezes até no mesmo tutorial / manual.

Uso 1: branch = ponteiro / referência a uma confirmação

O livro Pro Git (em3.1 - O que é um ramo), depois de mostrar o diagrama a seguir,

passa a definir um ramo como

simplesmente um ponteiro móvel leve para um desses commits.

Até onde eu sei, esse também é o significado de "ramificação" nas páginas de manual do Git.

Estou perfeitamente confortável com esta definição. Penso em uma ramificação apenas como uma referência que aponta para um commit específico no DAG, e o "tip commit" de uma ramificação é o commit apontado por essa referência. Por enquanto, tudo bem. Mas espere...

Uso 2: branch = um subgrafo do DAG

oTutorial do Atlassian Git introduz ramificações da seguinte maneira:

Uma ramificação representa uma linha de desenvolvimento independente.

O que eles querem dizer com isso, eu acho, é uma série de confirmações. Deixe-me refinar esse pensamento ... A única interpretação que faz sentido para mim é que o termo "ramo" também pode se referir aosubgrafo do DAG de confirmação do repositório composto por todos os commits alcançáveis a partir do commit de dica considerado.

No entanto, o livro Pro Git, por exemplo, também contém o diagrama a seguir (consulte3.4 - Fluxos de trabalho de ramificação),

o que parece contradizer minha interpretação, porque parece implicar que apenas cometeC2-C5 (nãoC1) pertencem aodevelop ramo, e que apenas confirmaC6-C7 (nãoC1-C5) pertencem aotopic ramo.

Acho esse uso ambíguo e vago, porque, se eu desenhar o DAG nessa fase, sem saber para onde as referências de ramificações apontaram no passado, e sem nenhuma suposição de qualquer hierarquia entre as três ramificações, tudo o que obteria é

Também acho alguns diagramas em outros recursos de aprendizado do Git confusos. Considere, em particular, o seguinte (retirado do vídeo de introdução doLynda.com - Treinamento Essencial do Git):

Aqui, a dica demaster éna realidade 534de (eHEAD aponta paramaster), mas a posição do rótulo "mestre" no diagrama é muito enganadora. O que esse rótulo deve descrever neste caso não está claro para mim ...

Editar: Eu encontrei desde entãoexcelente publicação no blog de Marc; aRamos seção ecoa minhas observações acima.