O que é melhor para pequenas correções de bugs e pequenos recursos - nomear ramos pelo número do ticket ou nomeá-los pela descrição do recurso?

10

Estou no meio de uma discordância (cordial, é claro) com minha liderança sobre a nomeação adequada de filiais. Isso se aplica a correções de bugs e ramificações de recursos pequenos, e não a ramificações de recursos de execução longa. Para ramificações de recursos de longa duração, concordamos que os nomes legíveis por humanos são melhores. Aqui estão os dois pontos de vista:

Meu:

Nomear ramificações de acordo com a equipe e o número do ticket é melhor. Torna mais fácil encontrá-los em nosso sistema de emissão de bilhetes e mais curto para digitar. Também facilita a pesquisa de ramificações relevantes no GIT ao procurar informações históricas sobre um ticket.

Exemplo:

team-name/12345
team-name/53719

Seu:

Nomear ramificações de acordo com seu recurso / funcionalidade. Isso facilita o preenchimento automático e é mais fácil de lembrar do que números individuais.

Exemplo:

team-name/fix-that-sql-bug
team-name/expand-http-parser

Um compromisso que ofereci é o seguinte:

team-name/12345-fix-that-sql-bug

Mas ele não gosta disso, pois mexe com o preenchimento automático do GIT.

Se isso for baseado principalmente em opiniões, fique à vontade para me orientar sobre como isso pode ser mais adequado para o SO - mas acho que as razões que dei podem ser alteradas / adicionadas para dar uma resposta empírica.

— Codeman
fonte

na minha experiência, a melhor nomeação de ramificações para pequenas correções de bugs e recursos pequenos costumava ser tronco (mesclar cedo, mesclar frequentemente => não há necessidade de isolar as alterações sem uma justificativa suficiente). É claro que isso não se aplica a correções críticas de porte regressivo para código de versões mais antigas em execução na produção, para o qual o isolamento é justificado mais do que suficiente (e para o qual, por sua vez, é natural nomear ramificações após tickets: afinal, você não está fazendo nada particularmente significativo como um recurso, você simplesmente está corrigindo um bug de produção crítico concreto que possui um ticket concreto) #

— 586

5

Nesse caso, parece que você pode comprometer uma convenção de nomenclatura com o número e a descrição:

Exemplo:

nome-da-equipe / (12345) -fix-that-sql-bug

nome-da-equipe / (53719) -expand-http-parser

Realmente não há resposta correta aqui, é subjetiva, dependendo do seu ponto de vista.

Mas se vocês dois se comprometem, obtêm o melhor dos dois mundos. Eu tento manter isso em mente quando temos discordâncias semelhantes em minha equipe.

Editar:

Para lidar com o problema de preenchimento automático, você pode colocar o ID numerado entre colchetes, dessa maneira, quando você digita uma ramificação que sempre digita (para ver as ramificações. Nesta lista, você pode ver a ID numerada e a descrição. Basta digitar alguns números, tabulação e

— dmck
fonte

Concordo e acrescentei isso - acho que é tolice discordar desse compromisso.

— precisa saber é

O preenchimento automático funciona apenas desde o início do nome da filial? você pode colocar o ID no final? Como não uso a funcionalidade de preenchimento automático, não estou familiarizada com ela.

— Dmck 6/08/13

sim, funciona do início ao fim - se você quiser obter team-name/12345-my-ticket-fix, deve digitar team-name/123TAB, essencialmente.

— Codeman 6/08/13

@ Pheonixblade9 Ver a minha edição para uma solução possível, colocando um (antes da ID deve impedi-lo de ter que saber o ID ao digitar o nome da ramificação

— dmck

1

Realmente não importa, desde que exista um sistema consistente que todos concordem e entendam.

Eu diria que, ao passar pelo número do ticket, seria mais fácil lembrar as coisas em que ramo trabalhar. Como eles se vinculam diretamente ao número da questão e não a uma descrição. Fazer apenas a descrição parece dificultar a lembrança de qual assunto específico deveria ser e poderia ficar muito tempo tentando evitar ser vago.

team-name/bug-that-has-specific-circumstances-to-occur-and-takes-alot-to-describe

— Schleis
fonte

0

Nomear algo apenas para tirar proveito do preenchimento automático é estúpido.

Concordo que um link para o rastreador de bugs é importante (mais importante do que um bom nome, pois define exatamente o problema que está sendo resolvido pelo ramo que algumas palavras não o fazem), mas ao mesmo tempo, é uma falha de usabilidade em esperar que as pessoas para saber a diferença entre os erros 7312 e 7213. Também é um fracasso esperar que as pessoas obtenham os números perfeitamente certos todas as vezes - um dia alguém se comprometerá com o ramo errado porque interpretou errado / digitou incorretamente 7312 para 7213. (alguém da minha equipe fez isso hoje!)

O mesmo acontece com os dois - numere o ramo e adicione uma descrição de texto muito curta apenas para funcionar como uma verificação. Eu colocaria o número em primeiro lugar - o preenchimento automático é o suficiente - já que você ainda precisa saber o texto da ramificação (por exemplo, "correção de bug para servidor" ou "correção de bug para servidor" - você ainda precisa saber se começar com f ou b!)

— gbjbaanb
fonte