Question Meilleures pratiques de dénomination de succursale git [fermé]


J'utilise un référentiel git local qui interagit avec le dépôt 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 ma malle. Mais nommer 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 branchement et de fusion, alors je peux répéter le nom de 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 des branches commencent à devenir longs et difficiles à manier.

J'ai appris en parcourant les vieilles discussions ici que je pourrais commencer à nommer des branches avec un / dans le nom, c.-à-d., 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?

Modifier: Personne n'a suggéré de conventions de nommage. Je supprime les branches quand j'en ai fini avec elles. Il m'arrive d'en avoir plusieurs à cause de la gestion qui ajuste constamment mes priorités. :) A titre d'exemple de 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 dépôt CVS du groupe. À ce moment-là, en raison de mon interaction imparfaite avec CVS, j'accomplirais ce commit et ensuite je tuerais cette branche. (J'ai vu trop d'étrangeté interagir avec CVS ​​si j'essaie de continuer à utiliser la même branche à ce moment-là.)


787
2017-11-07 21:29


origine


Réponses:


Voici quelques conventions de dénomination de branche que j'utilise et les raisons pour lesquelles

Conventions de dénomination de branche

  1. Utilisez des jetons de regroupement (mots) au début des noms de vos branches.
  2. Définissez et utilisez des jetons d'avance courts pour différencier les branches d'une manière qui soit 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 les chiffres 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 branches.

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

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

Jetons courts et bien définis

Choisissez des jetons courts afin qu'ils n'ajoutent pas trop de bruit à chacun de vos noms de branches. Je les utilise:

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 indiquer à quelle partie de votre flux de travail appartient chaque branche.

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 sont 'nouveaux', 'testés' et 'vérifiés'. Vous pouvez nommer vos branches avec des versions abrégées de ces étiquettes, toujours épelées de la même manière, pour les regrouper et pour vous rappeler à quel stade vous vous trouvez.

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

Vous pouvez rapidement identifier les branches qui ont atteint chaque étape et vous pouvez les regrouper facilement en utilisant les options de correspondance de formes 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 branches, 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 aussi mieux pour l'expansion de l'onglet (achèvement de la commande) 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 pièce 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 aussi bien que ceux incorporé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 à propos de la complétion des commandes et je peux aussi 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/*" 

Avertissement: Comme Slipp le fait remarquer 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. À l'intérieur de 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 programme de suivi des problèmes nomme des bogues avec des nombres décimaux. Je nomme mes branches connexes 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 seulement 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 bûches décorées sur une seule ligne, car les noms des branches peuvent absorber la plus grande partie de la ligne et abréger la partie visible de la bûche.

D'un autre côté, les noms de branches longs peuvent être plus utiles dans les "commits de fusion" si vous ne les réécrivez pas à la main. Le message de validation de fusion par défaut est Merge branch 'branch-name'. Vous trouverez peut-être plus utile d'afficher les messages de fusion Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' au lieu de juste Merge branch 'fix/CR15032'.


714
2018-05-19 23:25



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 intéresse, considérez le extension de flux à git. D'autres ont a 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" de cette branche. C'est celui utilisé pour la plupart des travaux sur les lignes principales. Communément nommé develop.

  • Plusieurs branches d'entités hors de la branche de développement. Nom basé sur le nom de l'entité. Ceux-ci seront fusionnés dans le développement, pas dans le master ou la libération des branches.

  • Libérez la branche pour tenir les versions candidates, avec seulement des corrections de bogues et aucune nouvelle fonctionnalité. Nom typique rc1.1.

Les corrections à chaud sont des branches éphémères pour les changements qui proviennent de master et vont dans master sans que la branche de développement soit impliquée.

enter image description here


227
2017-11-23 16:58



Ma préférence personnelle est de supprimer le nom de la branche après que j'ai 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 lance la ligne d'objet du message de commit dans le premier commit sur cette branche avec "Branch:" et inclue d'autres explications 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 sujet terminé, je me débarrasse du nom de la branche, en marquant parfois le commit pour référence ultérieure.

Cela rend la sortie de git branch plus utile aussi: il ne répertorie que les branches à longue durée de vie et les branches sujet actives, pas toutes les branches jamais.


42
2017-11-07 21:51



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

nom / fonctionnalité / numéro de suivi-numéro / description courte

ce qui se traduirait par:

mike / blogs / RSSI-12 / logo-fix

Les parties sont séparées par des barres obliques car celles-ci sont interprétées comme des dossiers dans SourceTree pour faciliter l'organisation. Nous utilisons Jira pour le suivi des problèmes, ce qui permet de rechercher plus facilement dans le système. Si vous incluez ce nombre, vous pouvez également rechercher ce problème dans Github lorsque vous essayez de soumettre une demande de pull.


25
2017-10-10 15:58



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 garder lisibles par l'homme, comme "ResizeWindow-43523". Cela facilite également les choses lorsque vous allez nettoyer des branches, puisque vous pouvez rechercher le bug associé. C'est comme ça que je nomme habituellement mes branches.

Étant donné que ces branches sont finalement fusionnées dans master, vous devriez ê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 jamais vous en avez besoin.


19
2017-11-11 06:24



Notez, comme illustré dans le commettre e703d7 ou commettre b6c2a0d  (Mars 2014), maintenant partie de Git 2.0, vous trouverez une autre convention de nommage (que vous pouvez appliquer aux branches).

"Quand vous avez besoin d'espace, utilisez le tiret" est une façon étrange de dire que vous ne devez pas utiliser d'espace.
  Étant donné qu'il est plus courant que les descriptions de lignes de commande utilisent des mots multiples en pointillé, vous ne voulez même pas utiliser d'espaces dans 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 git check-ref-format page de manuel).

Donc, pour chaque nom de branche qui serait représenté par une expression multi-mots, en utilisant un '-'(tiret) comme un séparateur est une bonne idée.


7
2018-06-14 19:41



Suite à la suggestion de farktronix, nous avons utilisé des numéros de tickets Jira 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 noté farktronix, si vous passez assez souvent d'une branche à l'autre, vous voudrez probablement moins de caractères. Ensuite, si vous avez besoin de connaître le nom de la branche, recherchez dans Jira les mots-clés associés dans le ticket si vous ne le connaissez pas. En outre, vous devez inclure le numéro de ticket dans chaque commentaire.

Si votre branche représente une version, il semble que la convention commune est d'utiliser le format xxx (exemple: "1.0.0") pour les noms de branches et vx.xx (exemple "v1.0.0") pour les noms de tags (pour éviter les conflits) . Voir également: est-il-une-norme-nommage-convention-pour-git-tags


4
2018-01-27 21:31