what - Existe uma convenção de nomenclatura padrão para tags do git?



git-tag (6)

A razão para o anterior 'v' é histórica. SCCS (cvs, rcs) mais antigos não conseguiam distinguir entre um identificador de tag e um número de revisão. Os identificadores de tags eram restritos para não começar com um valor numérico para que os números de revisão pudessem ser detectados.

Eu vi muitos projetos usando v1.2.3 como a convenção de nomenclatura para tags no git. Eu também vi algum uso 1.2.3 . Existe um estilo oficialmente endossado, ou existem bons argumentos para usar qualquer um deles?


Answer #1

A versão 1.0.0 do Semantic Versioning , de Tom Preston-Werner, do GitHub fame, tinha uma subespecificação que abordava isso:

Especificação de marcação (SemVerTag)

Esta sub-especificação deve ser usada se você usar um sistema de controle de versão (Git, Mercurial, SVN, etc) para armazenar seu código. O uso desse sistema permite que ferramentas automatizadas inspecionem seu pacote e determinem a conformidade e as versões lançadas do SemVer.

  1. Ao marcar lançamentos em um sistema de controle de versão, a tag de uma versão DEVE ser "vX.YZ", por exemplo, "v3.1.0" .

No entanto, após a discussion isso foi removido e não está mais presente na versão mais recente da especificação SemVer (2.0.0 no momento da gravação). Um tópico de discussão posterior no mesmo local entrou em maior profundidade e resultou em uma nova versão semântica "v1.2.3"? sendo added ao FAQ no branch master do SemVer, embora no momento da escrita (mais de 2 anos depois) esta mudança ainda não esteja presente na especificação oficialmente lançada.



Answer #3

Não que eu saiba.
Mas o Git não permitirá uma tag e uma ramificação do mesmo nome ao mesmo tempo, então se você tem uma ramificação " 1.1 " para 1.1 funciona, não coloque uma tag " 1.1 ", use por exemplo " v1.1 "


Answer #4

Parece haver duas convenções dominantes (supondo que você também cumpra algum padrão razoável para numerar os lançamentos):

  • v1.2.3
  • 1.2.3

As vantagens da v1.2.3 são que a documentação do Git (e também a documentação do Mercurial) usa esse formato em seus exemplos, e que várias "autoridades", como o kernel Linux e o próprio Git , o utilizam. (A versão semântica mencionada costumava usá-lo, mas não faz mais nada.)

As vantagens da versão 1.2.3 são que o gitweb ou o GitHub pode oferecer automaticamente um tarball ou um download zip do formulário packagename-$tag.tar.gz (e eu acho que está bem estabelecido que um tarball não deve ser chamado de package-v1.2.3.tar.gz ). Alternativamente, você pode usar o git describe diretamente para gerar números de versão do tarball. Para projetos leves sem um processo de lançamento formal, essas possibilidades podem ser bastante convenientes. Também deve ser notado que o Versioning Semântico não é de forma alguma o único padrão universalmente aceito para a numeração de versões. E projetos notáveis, como o GNOME, assim como inúmeros outros projetos, usam o nome da tag 1.2.3 .

Eu acho que é provavelmente tarde demais para consolidar essas posições. Como sempre, seja consistente e faça sentido.

Atualização: Como mencionado this comentário, o GitHub agora oferece um nome de tarball com o 'v' retirado da tag.


Answer #5

Usamos ramificações e tags para trabalhos específicos do release, seguidos pelo release real, respectivamente:

o---o-----o---o---o--- ...   master
     \   /       /
      \ /       /
       o-------o--- ...      1.6 branch

Todo desenvolvedor toma uma decisão mental sobre se o trabalho que está prestes a cometer é aplicável apenas para master ou se ele também é relevante para o branch. Você pode ver que as alterações feitas na ramificação são mescladas no mestre, mas algumas alterações no mestre nunca irão para a ramificação (ou seja, aquelas que não são destinadas à versão 1.6, neste exemplo).

Quando estamos prontos para lançá-los, marcamos e depois mesclamos uma última vez, e nomeamos a tag com o mesmo nome da ramificação, mas com um identificador extra sobre qual versão específica ela é, por exemplo, "1.6-release" ou "1,6-beta" ou "1,6-rc2", et cetera.

... ------o---o---o--o---o--- ...   master
         /       /
        /       /
... ---o------(*)--- ...      1.6 branch
          1.6-release




git-tag