Quels sont quelques exemples de pratiques couramment utilisées pour nommer les branches git? [fermé]

J'utilise un référentiel git local interagissant avec le référentiel CVS de mon groupe depuis plusieurs mois, maintenant. J'ai fait un nombre presque névrotique de branches, dont la plupart ont heureusement fusionné dans mon tronc. Mais la dénomination commence à devenir un problème. Si j'ai une tâche facilement nommée avec une simple étiquette, mais je l'accomplis en trois étapes qui incluent chacune leur propre situation de branche et de fusion, alors je peux répéter le nom de la branche à chaque fois, mais cela rend l'histoire un peu confuse. Si je deviens plus précis dans les noms, avec une description distincte pour chaque étape, alors les noms de branche commencent à devenir longs et difficiles à manier.

J'ai appris en parcourant les anciens threads ici que je pouvais commencer à nommer les branches avec un / dans le nom, c'est-à-dire, sujet / tâche, ou quelque chose comme ça. Je peux commencer à le faire et voir si cela aide à mieux organiser les choses.

Quelles sont les meilleures pratiques pour nommer les branches git?

Edit: Personne n'a suggéré de convention de nommage. Je supprime les branches lorsque j'en ai fini avec elles. Il se trouve que j'en ai plusieurs à cause de la gestion qui ajuste constamment mes priorités. :) Pour illustrer pourquoi je pourrais avoir besoin de plus d'une branche sur une tâche, supposons que je doive valider le premier jalon discret de la tâche dans le référentiel CVS du groupe. À ce stade, en raison de mon interaction imparfaite avec CVS, j'effectuais ce commit et puis tuais cette branche. (J'ai vu trop de bizarreries interagir avec CVS ​​si j'essaie de continuer à utiliser la même branche à ce stade.)

Voici quelques conventions de dénomination de branche que j'utilise et les raisons de celles-ci

Conventions de dénomination des branches

1. Utilisez des jetons de regroupement (mots) au début des noms de vos branches.
2. Définissez et utilisez des jetons de plomb courts pour différencier les branches d'une manière significative pour votre flux de travail.
3. Utilisez des barres obliques pour séparer les parties de vos noms de branche.
4. N'utilisez pas de nombres nus comme pièces principales.
5. Évitez les noms descriptifs longs pour les branches à longue durée de vie.

Jetons de groupe

Utilisez des jetons de "regroupement" devant les noms de vos succursales.

group1/foo
group2/foo
group1/bar
group2/bar
group3/bar
group1/baz

Les groupes peuvent être nommés comme bon vous semble pour correspondre à votre flux de travail. J'aime utiliser des noms courts pour le mien. Lisez la suite pour plus de clarté.

Jetons courts et bien définis

Choisissez des jetons courts pour ne pas ajouter trop de bruit à chacun de vos noms de branche. J'utilise ceux-ci:

wip       Works in progress; stuff I know won't be finished soon
feat      Feature I'm adding or expanding
bug       Bug fix or experiment
junk      Throwaway branch created to experiment

Chacun de ces jetons peut être utilisé pour vous dire à quelle partie de votre flux de travail chaque branche appartient.

Il semble que vous ayez plusieurs branches pour différents cycles de changement. Je ne sais pas quels sont vos cycles, mais supposons qu'ils soient «nouveaux», «testés» et «vérifiés». Vous pouvez nommer vos branches avec des versions abrégées de ces balises, toujours orthographiées de la même manière, à la fois pour les regrouper et pour vous rappeler à quelle étape vous vous trouvez.

new/frabnotz
new/foo
new/bar
test/foo
test/frabnotz
ver/foo

Vous pouvez rapidement savoir quelles branches ont atteint chaque étape différente, et vous pouvez les regrouper facilement en utilisant les options de correspondance de motifs de Git.

$ git branch --list "test/*"
test/foo
test/frabnotz

$ git branch --list "*/foo"
new/foo
test/foo
ver/foo

$ gitk --branches="*/foo"

Utilisez des barres obliques pour séparer les pièces

Vous pouvez utiliser la plupart des délimiteurs que vous aimez dans les noms de branche, mais je trouve que les barres obliques sont les plus flexibles. Vous préférerez peut-être utiliser des tirets ou des points. Mais les barres obliques vous permettent de renommer une branche lorsque vous poussez ou récupérez vers / depuis une télécommande.

$ git push origin 'refs/heads/feature/*:refs/heads/phord/feat/*'
$ git push origin 'refs/heads/bug/*:refs/heads/review/bugfix/*'

Pour moi, les barres obliques fonctionnent également mieux pour l'expansion des onglets (achèvement des commandes) dans mon shell. La façon dont je l'ai configuré, je peux rechercher des branches avec différentes sous-parties en tapant les premiers caractères de la partie et en appuyant sur la touche TAB. Zsh me donne alors une liste de branches qui correspondent à la partie du jeton que j'ai tapé. Cela fonctionne pour les jetons précédents ainsi que pour les jetons intégrés.

$ git checkout new<TAB>
Menu:  new/frabnotz   new/foo   new/bar


$ git checkout foo<TAB>
Menu:  new/foo   test/foo   ver/foo

(Zshell est très configurable pour l'achèvement de la commande et je pourrais également le configurer pour gérer les tirets, les traits de soulignement ou les points de la même manière. Mais je choisis de ne pas le faire.)

Il vous permet également de rechercher des branches dans de nombreuses commandes git, comme ceci:

git branch --list "feature/*"
git log --graph --oneline --decorate --branches="feature/*" 
gitk --branches="feature/*" 

Attention: comme le souligne Slipp dans les commentaires, les barres obliques peuvent causer des problèmes. Parce que les branches sont implémentées en tant que chemins, vous ne pouvez pas avoir une branche nommée "foo" et une autre branche nommée "foo / bar". Cela peut être déroutant pour les nouveaux utilisateurs.

N'utilisez pas de nombres nus

N'utilisez pas de nombres nus (ou de nombres hexadécimaux) dans le cadre de votre schéma de dénomination de branche. Dans l'extension de tabulation d'un nom de référence, git peut décider qu'un nombre fait partie d'un sha-1 au lieu d'un nom de branche. Par exemple, mon outil de suivi des problèmes nomme les bogues avec des nombres décimaux. Je nomme mes branches liées CRnnnnn plutôt que simplement nnnnn pour éviter toute confusion.

$ git checkout CR15032<TAB>
Menu:   fix/CR15032    test/CR15032

Si j'essayais de développer uniquement 15032, git ne serait pas sûr de vouloir rechercher les noms de SHA-1 ou de branche, et mes choix seraient quelque peu limités.

Évitez les noms descriptifs longs

Les noms de branche longs peuvent être très utiles lorsque vous consultez une liste de branches. Mais cela peut gêner la lecture des journaux d'une ligne décorés, car les noms de branche peuvent consommer la majeure partie de la ligne unique et abréger la partie visible du journal.

D'un autre côté, les noms de branche longs peuvent être plus utiles dans les «validations de fusion» si vous ne les réécrivez pas habituellement à la main. Le message de validation de fusion par défaut est Merge branch 'branch-name'. Il peut être plus utile que les messages de fusion apparaissent au Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted'lieu de simplement Merge branch 'fix/CR15032'.

Un modèle de branchement Git réussi par Vincent Driessen a de bonnes suggestions. Une image est ci-dessous. Si ce modèle de branchement vous plaît, considérez l' extension de flux à git . D'autres ont commenté le flux

Le modèle de Driessen comprend

• Une branche principale, utilisée uniquement pour la publication. Nom typique master.

• Une branche "développer" hors de cette branche. C'est celui utilisé pour la plupart des travaux sur la ligne principale. Communément nommé develop.

• Plusieurs branches de fonction hors de la branche de développement. Nom basé sur le nom de la fonction. Ceux-ci seront fusionnés à nouveau dans develop, et non dans les branches master ou release.

• Branche de publication pour contenir les versions candidates, avec seulement des corrections de bugs et aucune nouvelle fonctionnalité. Nom typique rc1.1.

Les correctifs sont des branches de courte durée pour les modifications qui proviennent de master et iront dans master sans que la branche de développement soit impliquée.

Ma préférence personnelle est de supprimer le nom de la branche après avoir terminé avec une branche de sujet.

Au lieu d'essayer d'utiliser le nom de la branche pour expliquer la signification de la branche, je commence la ligne d'objet du message de validation dans le premier commit sur cette branche avec "Branche:" et j'inclus des explications supplémentaires dans le corps du message si le sujet ne me donne pas assez d'espace.

Le nom de la branche dans mon utilisation est purement une poignée pour faire référence à une branche de sujet tout en travaillant dessus. Une fois le travail sur la branche du sujet terminé, je me débarrasse du nom de la branche, parfois en marquant le commit pour référence ultérieure.

Cela rend également la sortie de git branchplus utile: elle ne répertorie que les branches de longue durée et les branches de sujet actives, pas toutes les branches jamais.

J'ai mélangé et assorti à partir de différents schémas que j'ai vus et basés sur l'outillage que j'utilise.
Donc, mon nom de branche complété serait:

nom / fonctionnalité / numéro de suivi des problèmes / brève description

ce qui se traduirait par:

micro / blogs / RSSI-12 / logo-fix

Les parties sont séparées par des barres obliques car elles sont interprétées comme des dossiers dans SourceTree pour une organisation facile. Nous utilisons Jira pour notre suivi des problèmes, donc l'inclusion du numéro facilite la recherche dans le système. L'inclusion de ce numéro le rend également consultable lorsque vous essayez de trouver ce problème dans Github lorsque vous essayez de soumettre une demande d'extraction.

Pourquoi faut-il trois branches / fusions pour chaque tâche? Pouvez-vous expliquer plus à ce sujet?

Si vous utilisez un système de suivi des bogues, vous pouvez utiliser le numéro de bogue dans le nom de la branche. Cela gardera les noms de branche uniques, et vous pouvez les préfixer avec un mot court et descriptif ou deux pour les rendre lisibles par l'homme, comme "ResizeWindow-43523". Cela facilite également les choses lorsque vous nettoyez des branches, car vous pouvez rechercher le bogue associé. C'est ainsi que je nomme habituellement mes succursales.

Étant donné que ces branches sont finalement fusionnées à nouveau dans le maître, vous devez être sûr de les supprimer après la fusion. Sauf si vous fusionnez avec --squash, toute l'histoire de la branche existera toujours si vous en avez besoin.

Remarque, comme illustré dans la validation e703d7 ou la validation b6c2a0d (mars 2014), désormais intégrée à Git 2.0, vous trouverez une autre convention de dénomination (que vous pouvez appliquer aux branches).

"Lorsque vous devez utiliser l'espace, utilisez le tiret" est une façon étrange de dire que vous ne devez pas utiliser d'espace.
Dans la mesure où il est plus courant que les descriptions de ligne de commande utilisent plusieurs mots en pointillés, vous ne souhaitez même pas utiliser d'espaces à ces endroits.

Un nom de branche ne peut pas avoir d'espace (voir " Quels caractères sont illégaux dans un nom de branche? " Et la git check-ref-formatpage de manuel ).

Ainsi, pour chaque nom de branche qui serait représenté par une expression composée de plusieurs mots, l'utilisation d'un ' -' (tiret) comme séparateur est une bonne idée.

Suite à la suggestion de farktronix, nous avons utilisé des numéros de billets Jira pour similaires dans mercurial, et je prévois de continuer à les utiliser pour les branches git. Mais je pense que le numéro de billet lui-même est probablement assez unique. Bien qu'il puisse être utile d'avoir un mot descriptif dans le nom de la branche comme l'a noté farktronix, si vous changez assez souvent de branche, vous voudrez probablement moins taper. Ensuite, si vous avez besoin de connaître le nom de la succursale, recherchez dans Jira les mots-clés associés dans le ticket si vous ne le connaissez pas. De plus, vous devez inclure le numéro de ticket dans chaque commentaire.

Si votre branche représente une version, il semble que la convention courante consiste à utiliser le format xxx (exemple: "1.0.0") pour les noms de branche et vx.xx (exemple "v1.0.0") pour les noms de balise (pour éviter les conflits) . Voir aussi: existe-t-il une convention de dénomination standard pour les balises git