Como você consegue um esquema de versionamento numérico com o Git?

125

Minha organização está pensando em mudar do SVN para o Git. Um argumento contra a movimentação é o seguinte:

Como fazemos as versões?

Temos uma distribuição do SDK baseada na plataforma NetBeans. Como as revisões do SVN são números simples, podemos usá-las para estender os números de versão de nossos plugins e versões do SDK. Como lidamos com isso quando nos mudamos para o Git?

Soluções possíveis:

  • Usando o número de compilação do Hudson (Problema: você precisa verificar o Hudson para correlacionar isso a uma versão real do Git)
  • Atualizando manualmente a versão para todas as noites e estável (Problema: curva de aprendizado, erro humano)

Se alguém encontrou um problema semelhante e o resolveu, adoraríamos saber como.

    
por Erlend 28.03.2012 / 20:18
fonte

5 respostas

141

Use as tags para marcar confirmações com números de versão:

git tag -a v2.5 -m 'Version 2.5'

Enviar tags para upload - isso não é feito por padrão:

git push --tags

Em seguida, use o comando descrever :

git describe --tags --long

Isso fornece uma string do formato:

v2.5-0-gdeadbee
^    ^ ^^
|    | ||
|    | |'-- SHA of HEAD (first seven chars)
|    | '-- "g" is for git
|    '---- number of commits since last tag
|
'--------- last tag
    
por 28.03.2012 / 20:55
fonte
38

Isso surgiu em alguns projetos para mim. A melhor solução que tive até agora é gerar um número de versão como este:

x.y. < número de confirmações > .r < git-hash >

Normalmente, ele é gerado pelo nosso sistema de compilação usando uma combinação de algum arquivo ou tag estático para obter os principais números de revisão, git rev-list HEAD | wc -l (que foi mais rápido do que usar git log ) e git rev-parse HEAD . O raciocínio foi o seguinte:

  1. Precisamos da capacidade de ter versões explícitas de alto nível (ou seja, x.y)
  2. Quando o desenvolvimento paralelo estava acontecendo, precisávamos NUNCA gerar o mesmo número de versão.
  3. Queríamos rastrear facilmente de onde uma versão veio.
  4. Quando linhas paralelas foram mescladas, queríamos que a nova versão fosse mais alta do que qualquer uma das ramificações.

O número 2 é invisível para a maioria das pessoas, mas é realmente importante e realmente difícil com o controle de origem distribuído. O SVN ajuda com isso, fornecendo um único número de revisão. Acontece que uma contagem de commits é o mais próxima possível, enquanto magicamente resolve o # 4 também. Na presença de ramificações, isso ainda não é único, e nesse caso adicionamos o hash, que também resolve o # 3.

A maior parte disso foi acomodar a implantação via pip do Python. Isso garantiu que pip install seria talvez um pouco estranho durante o desenvolvimento paralelo (ou seja, pacotes de pessoas em diferentes ramos se misturariam, mas de uma maneira determinística), mas que após as mesclagens, tudo seria resolvido. Exceto a presença de uma rebase exposta ou alteração, isso funcionou muito bem para os requisitos acima.

Caso você esteja se perguntando, nós escolhemos colocar o r na frente do hash devido a algumas estranhezas de como o pacote do Python manipula letras em números de versão (ou seja, ae são menores que 0, o que faria "1.3.10. a1234 "<" 1.3.10 "<" 1.3.10.1234 ").

    
por 05.06.2012 / 00:57
fonte
8

As versões são identificadas com os hashes SHA1 de todos os arquivos na árvore de diretórios armazenada no momento do check-in. Este hash é armazenado junto com os hashes do check-in pai (s) para que o histórico completo possa ser lido.

Dê uma olhada no processo de usar 'git-describe' por meio de GIT-VERSION-GEN e como você pode adicionar isso através de seu processo de criação ao marcar sua versão.

Aqui está um bom blog que dá um exemplo de como conseguir o que você quer:

link

    
por 28.03.2012 / 20:51
fonte
7

Isso pode ser um pouco exagerado, mas deixarei você saber como fazemos isso.

Usamos uma estrutura de ramificação muito semelhante a this .

O Hudson constrói nossas ramificações "desenvolver" e incrementa números de compilação a partir de 0. O número de compilação é exclusivo para cada projeto e é marcado no controle de versão. A razão é que você pode dizer exatamente de onde veio o desenvolvimento da filial 42, por exemplo (cada projeto pode ter vários ramos em paralelo, porque cada projeto pode ter várias equipes trabalhando em diferentes aspectos do projeto).

Quando decidimos que uma determinada compilação é boa o suficiente para ser lançada, a confirmação que acionou essa compilação é marcada com um número de versão da release, que é decidido pelo marketing. Isso significa que as equipes de desenvolvimento não se importam com o número da versão final e o marketing está livre para se misturar com números de versão da maneira que achar melhor. O número da versão final e o número da compilação estão presentes no produto lançado.

Exemplo: 2.1.0 compilação 1337

Isso significa que, para uma versão específica do produto, você pode dizer qual foi a última equipe a trabalhar nela e pode consultar o git para todos os commits que serão lançados para diagnosticar um problema, se necessário.

    
por 29.03.2012 / 01:48
fonte
-6

Pro Git em seção 7.2 "Git Attributes" na seção "Keyword" Expansion contém um bom exemplo do uso de filtros smudge & clean para gerar palavras-chave no estilo RCS. Você pode usar a mesma técnica para incorporar alguma-versão-string em código, formatado e calculado de acordo com suas regras . Você ainda pode usar git describe como um ponto de partida, mas você tem a possibilidade de se transformar em qualquer forma mais apropriada e obter de v2.5-14-feebdaed, por exemplo, clean 2.5.14

    
por 28.03.2012 / 23:34
fonte