Quel est le meilleur pour les petites corrections de bugs et les petites fonctionnalités - nommer les branches par numéro de ticket ou les nommer par description de fonctionnalité?

10

Je suis au milieu d'un désaccord (cordial, bien sûr) avec mon avance sur le nom des branches. Cela s'applique aux correctifs de bogues et aux petites branches de fonctionnalités, pas aux branches de fonctionnalités de longue durée. Pour les branches de fonctionnalités de longue durée, nous convenons que les noms lisibles par l'homme sont meilleurs. Voici les deux points de vue:

Mien:

Il est préférable de nommer les succursales en fonction de leur équipe et du numéro de billet. Cela les rend plus faciles à trouver dans notre système de billetterie et plus courts à taper. Cela facilite également la recherche de branches pertinentes dans GIT lors de la recherche d'informations historiques sur un ticket.

Exemple:

team-name/12345
team-name/53719

Le sien:

Nommer les branches en fonction de leur caractéristique / fonctionnalité. Il facilite la saisie semi-automatique et est plus facile à mémoriser que les chiffres individuels.

Exemple:

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

Un compromis que j'ai proposé est le suivant:

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

Mais il n'aime pas cela, car cela gâche la saisie semi-automatique de GIT.

Si cela est principalement basé sur l'opinion, n'hésitez pas à me donner des conseils sur la façon dont cela peut être mieux adapté à SO - mais je pense que les raisons que j'ai données peuvent être modifiées / ajoutées pour donner une réponse empirique.

— Codeman
source

d'après mon expérience, le meilleur nom pour les branches pour les petites corrections de bugs et les petites fonctionnalités était souvent un tronc (fusion précoce, fusion souvent => pas besoin d'isoler les changements sans justification suffisante). Bien sûr, cela ne s'applique pas au back-porting des correctifs critiques vers les anciennes versions de code en cours de production, pour lesquelles l'isolement est plus que suffisant (et pour lequel, à son tour, il est naturel de nommer les branches d'après les tickets: après tout, vous ne faites rien de particulièrement significatif en tant que fonctionnalité, vous

— gnat

5

Dans ce cas, il semble que vous puissiez à la fois faire un compromis sur une convention de dénomination qui a à la fois le numéro et la description:

Exemple:

nom-équipe / (12345) -fix-that-sql-bug

nom-équipe / (53719) -expand-http-parser

Il n'y a vraiment pas de bonne réponse ici, elle est subjective selon votre point de vue.

Mais si vous comprenez tous les deux, vous obtenez le meilleur des deux mondes. J'essaie de garder cela à l'esprit lorsque nous avons des désaccords similaires au sein de mon équipe.

Éditer:

Pour résoudre le problème de saisie semi-automatique, vous pouvez mettre l'ID numéroté entre crochets, de cette façon lorsque vous allez taper une branche que vous tapez toujours (pour voir les branches. De cette liste, vous pourrez voir l'ID numéroté et la description. Entrez simplement quelques chiffres, onglet, et cela

— dmck
source

Je suis d'accord et j'ai ajouté ceci - je pense qu'il est idiot de ne pas être d'accord avec ce compromis.

— Codeman

La saisie semi-automatique ne fonctionne-t-elle qu'au début du nom de la branche? pouvez-vous mettre l'ID à la fin? Je n'utilise pas la fonctionnalité de saisie semi-automatique, je ne la connais donc pas.

— dmck

oui, cela fonctionne du début à la fin - si vous voulez obtenir, team-name/12345-my-ticket-fixvous devez taper team-name/123TAB, essentiellement.

— Codeman

@ Pheonixblade9 Voir ma modification pour une solution possible, en mettant un (avant que l'ID ne vous empêche d'avoir à connaître l'ID lors de la saisie du nom de la branche

— dmck

1

Cela n'a vraiment pas d'importance tant qu'il existe un système cohérent que tout le monde accepte et comprend.

Je dirais cependant que le fait de passer par le numéro de ticket permettrait de se souvenir plus facilement de la branche sur laquelle travailler. Comme ils sont directement liés au numéro du problème plutôt qu'à une description. Ne faire que la description semble rendre plus difficile de se rappeler quel problème spécifique il est censé être et pourrait devenir de longue haleine en essayant d'éviter d'être vague.

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

— Schleis
source

0

Nommer quelque chose uniquement pour profiter de la saisie semi-automatique est stupide.

Je suis d'accord qu'un lien vers le traqueur de bogues est important (plus important qu'un bon nom car il définit exactement le problème résolu par la branche que quelques mots ne le font pas) mais en même temps, c'est une incapacité d'utilisation à attendre des gens pour connaître la différence entre le bug # 7312 et # 7213. De plus, il est impossible de s'attendre à ce que les gens obtiennent les chiffres parfaitement à chaque fois - un jour, quelqu'un s'engagera dans la mauvaise branche parce qu'il a mal lu / mal tapé 7312 pour 7213. (quelqu'un de mon équipe l'a fait aujourd'hui!)

Faites donc les deux - numérotez la branche et ajoutez une description textuelle très courte juste pour agir comme une vérification. Je mettrais le numéro en premier - la saisie semi-automatique soit damnée - car vous devez toujours connaître le texte de la branche de toute façon (par exemple "bug-fix-for-server" ou "fix-bug-for-server" - vous devez toujours savoir si ça commence par f ou b!)

— gbjbaanb
source