Boa convenção de nomenclatura para ramificações nomeadas em {DVCS} de sua escolha

16

Estamos integrando o Mercurial lentamente em nosso escritório e desenvolvendo a Web, começamos a usar filiais nomeadas.

No entanto, ainda não encontramos uma boa convenção quanto a nomear nossas filiais.

Nós tentamos:

FeatureName (pode ver isso causando problemas na linha)
DEVInitial_FeatureName (pode ficar confuso quando o desenvolvedor entra e sai)
{uniqueID (int)} _ Recurso

Até agora, o uniqueID_featureName está ganhando, estamos pensando em mantê-lo em um pequeno banco de dados apenas para referência.

Ele teria: branchID (int), featureName (varchar), featureDescription (varchar), date, who etc ...

Isso nos daria ramos como: 1_NewWhizBangFeature, 2_NowWithMoreFoo, ... e teríamos uma referência fácil sobre o que esse ramo faz sem ter que verificar o log.

Alguma solução melhor por aí?

version-control mercurial

— jfrobishow
fonte

14

Se você não possui um rastreador de problemas, recomendo configurar um e usar {nome do rastreador de problemas} _ {número do ticket}. Quando alguém daqui a alguns anos registrar um bug e você não souber exatamente como o recurso deveria funcionar, será fácil anotar o arquivo e voltar para onde o usuário pode ter solicitado a funcionalidade exata.

— Asa Ayers
fonte

Concordamos que temos um rastreador de erros e estamos planejando usar o ID do bug no nome do ramo para correções de erros. Minha pergunta era mais para desenvolvimento totalmente novo, quando você não está consertando nada, mas adicionando algo totalmente novo. Suponho que poderíamos criar um tíquete de aprimoramento idiota e partir daí.

— Jfrobishow 1/10/10

5

Você absolutamente deve criar tickets para novos recursos. O trabalho também deve ser rastreado. +1 por exigir um ID exclusivo.

— ASHelly #

Se você colocar todos os detalhes dos novos recursos no rastreador, alguém mais tarde poderá verificar se está funcionando como projetado ou se realmente existe um erro. Eu trabalho em uma equipe de desenvolvimento que mantém um programa de 5 anos ou mais. Há momentos em que o cliente arquiva um bug e, quando pesquisamos, descobrimos que está funcionando como projetado e o desenvolvedor original e o solicitante original desaparecem. Temos situações semelhantes em que não sabemos por que as coisas são do jeito que são e se os recursos não estavam no rastreador, não teríamos como descobrir.

— Asa Ayers

2

Sugiro mantê-lo simples e nomear ramos de acordo com a convenção FeatureName(ou feature-name). Sim, isso significa um espaço para nome compartilhado, mas isso raramente é um problema no mundo real. Depois que um recurso é concluído e completamente mesclado à linha principal, o ramo pode ser excluído com segurança.

A idéia principal do controle de versão distribuído é que deve ser fácil ramificar, a introdução de burocracia adicional, como o ID exclusivo obrigatório, só tornará isso mais difícil.

— Adam Byrtek
fonte

1

Eu concordo, este é o caminho a percorrer. Em que mundo você teria tantos ramos que não pode evitar a colisão?

— alternativa

É justo, obter uma descrição vinculada ao nome, acho que é mais importante para nós ... o commit inicial deve conter, mas não conheço nenhuma maneira de extrair isso rapidamente.

— Jfrobishow 1/10/10

1

Em um grande ambiente corporativo, permitir que os desenvolvedores criem nomes de recursos causará dores de cabeça mais cedo ou mais tarde.

— ASHelly #

1

Entendo, porque no "grande ambiente corporativo" os desenvolvedores não podem ser confiáveis. Mas espere, eles também inventam nomes para variáveis, funções e arquivos. Deveríamos criar um comitê para controlar isso também! (ironia)

— Adam Byrtek 01/10/10

2

Eu recomendo usar esse formulário (como exemplo):

BUG_ID
ID do BUG #
TICKET_ID
ID do TICKET #
feature_bla-bla-bla
release-x.xx.xx
release_x.xx.xx
build_2010-20-12
build_4565
BRANCH_x.xx.xx

Basta selecionar bons prefixos (para permitir a saída do filtro de ramificações hg ), regra de capitalização e delimitador entre prefixo e ID / nomes.

— gavenkoa
fonte

Marcamos com +1 o BUGID_ {freeCamelCasedTextDescription} no final.

— Jrobishow