Meilleures pratiques de dénomination de branche git

Question

J'ai été en utilisant un dépôt git local interagissant avec mon groupe du référentiel CVS pour plusieurs mois, maintenant. J'ai fait un presque névrotique nombre de branches, dont la plupart ont, heureusement, fusionnée dans mon coffre. Mais la dénomination est en train de devenir un problème. Si j'ai une tâche facile nommé avec un simple label, mais je le réaliser en trois étapes qui comprennent chacune leur propre branche et de fusion de la situation, alors je peux répéter le nom de la branche à chaque fois, mais qui rend l'histoire un peu confuse. Si j'ai plus précis dans le choix des noms, avec une description distincte pour chaque étape, puis la direction des noms commencent à être longues et difficiles à manier.

J'ai appris en regardant à travers les vieux fils ici que j'ai pu commencer à appeler les branches avec un / dans le nom, c'est à dire, le sujet/tâche, ou quelque chose comme ça. Je peut commencer à faire cela et voir si cela permet de garder les choses de mieux en mieux organisés.

Quelles sont les meilleures pratiques pour nommer les branches git?

Edit: Personne n'a réellement proposé aucune des conventions de nommage. Je ne supprimer des branches quand je suis fait avec eux. Je viens de passer plusieurs autour en raison de la gestion de l'adaptation constante de mes priorités. :) Comme un exemple de pourquoi aurais-je besoin de plus d'une branche sur une tâche, supposons que j'ai besoin de commettre le premier discrète étape importante dans la tâche du groupe référentiel CVS. À ce moment, à cause de mon imparfait de l'interaction avec les CV, je voudrais effectuer que s'engager et ensuite de tuer cette branche. (J'ai vu trop d'étrangeté, de l'interaction avec CVS si j'essaie de continuer à utiliser la même branche en ce moment.)

Answer 1

Voici quelques-direction des conventions de nommage que j'utilise et les raisons de leur

Direction générale des conventions de nommage

1. Utilisez le groupement des tokens (mots) au début de vos noms de branche.
2. Définir et utiliser des jetons en plomb pour différencier les branches de façon significative à votre flux de travail.
3. Utiliser des barres obliques pour séparer les parties de vos noms de branche.
4. Ne pas utiliser les numéros nus comme des plus grands.
5. Éviter les longs noms descriptifs pour longue durée de vie des branches.

Groupe de jetons

L'utilisation de "groupement" jetons en face de vos noms de branche.

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

Les groupes peuvent être nommée ce que vous voulez pour correspondre à votre flux de travail. J'aime utiliser des noms pour le mien. Lire la suite pour plus de clarté.

Court bien défini de jetons

Choisissez court de jetons afin de ne pas ajouter trop de bruit pour chacun de vos noms de branche. J'utilise ces:

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 peuvent être utilisés pour vous dire à quelle partie de votre flux de production de chaque branche appartient.

Il semble que vous avez plusieurs branches pour les différents cycles de changement. Je ne sais pas ce que vos cycles sont, mais admettons qu'ils sont "nouveaux", "testing" et "vérifiée". Vous pouvez nommer vos branches avec des versions abrégées de ces balises, toujours orthographié de la même façon, à la fois du groupe et de vous rappeler à quel stade vous êtes dans.

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

Vous pouvez savoir rapidement branches qui ont atteint chaque étape, et vous pouvez les regrouper facilement à l'aide de Git du modèle options de correspondance.

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

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

$ gitk --branches="*/foo"

Utiliser des barres obliques pour séparer les parties

Vous pouvez utiliser la plupart un délimiteur vous comme dans les noms de branche, mais je trouve que des barres obliques pour être le plus flexible. Vous préférerez peut-être utiliser des tirets ou des points. Mais les slashes vous permettent de faire certains de la branche de renommer en poussant ou chercher à/à partir d'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 également mieux travailler pour l'onglet d'extension (fin de commande) dans ma coquille. La façon dont je l'ai configuré je peux rechercher les branches avec des sous-parties en tapant les premiers caractères de la partie et en appuyant sur la touche de TABULATION. Zsh, puis me donne une liste des branches, qui correspondent à la partie du jeton que j'ai tapé. Cela fonctionne pour les précédentes jetons ainsi que ceux 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 sur d'achèvement de commande et j'ai pu également le configurer pour gérer des tirets, des traits de soulignement ou de points de la même façon. Mais je choisis de ne pas.)

Il vous permet également de rechercher des succursales dans de nombreux commandes git, comme ceci:

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

Avertissement: Comme Slipp points dans les commentaires, les barres obliques peuvent causer des problèmes. Parce que les branches sont mises en œuvre comme des chemins, vous ne pouvez pas avoir une branche nommée "toto" et une autre branche nommée "foo/bar". Cela peut être déroutant pour les nouveaux utilisateurs.

Ne pas utiliser les numéros nus

Ne pas utiliser des numéros nus (ou les nombres hexadécimaux) dans le cadre de votre branche schéma de nommage. À l'intérieur de l'onglet d'extension d'un nom de référence, git peut décider qu'un nombre est partie d'un sha-1 au lieu d'un nom de branche. Par exemple, mon problème de tracker les noms de bugs avec des nombres décimaux. J'ai le nom de mon liée branches CRnnnnn plutôt que de simplement nnnnn pour éviter la confusion.

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

Si j'ai essayé de développer juste 15032, git serait pas si je voulais de recherche SHA-1 ou d'une branche noms, et mon choix serait un peu limité.

Éviter les longs noms descriptifs

Longtemps les noms de branche peut être très utile lorsque vous êtes à la recherche à une liste de branches. Mais il peut obtenir de la manière quand on regarde décorée d'une ligne de journaux comme les noms de branche peut consommer jusqu'à plus de la ligne et d'abréger la partie visible du journal.

D'autre part longtemps les noms de branche peut être plus utile dans la "fusion s'engage" si vous ne faites pas habituellement de les réécrire à la main. La fusion par défaut message de commit est - Merge branch 'branch-name'. Vous pouvez trouver qu'il est plus utile de fusionner les messages apparaissent comme des Merge branch 'fix/CR15032/crash-when-unformatted-disk-inserted' au lieu de simplement en Merge branch 'fix/CR15032'.

Answer 2

Un modèle de branchement Git réussi par Vincent Driessen a de bonnes suggestions. Si ce modèle de branchement vous intéresse, considérez l' extension de flux à git . D'autres ont commenté sur le flux

Answer 3

J'ai mélangé de différents régimes que j'ai vu et basé sur les outils que j'utilise. Donc, mon terminé nom de la branche serait:

nom/fonction/question-tracker-nombre/short-description

ce qui se traduirait par:

mike/blogs/RSSI-12/logo-fix

Les parties sont séparées par des barres obliques parce que ceux qui sont interprétés comme des dossiers dans SourceTree pour faciliter l'organisation. Nous utilisons Jira pour notre problème de suivi, y compris le nombre, il est plus facile de chercher dans le système. Y compris ce nombre rend également consultable en essayant de trouver la question à l'intérieur de Github lors de la tentative de soumettre une demande d'extraction.

Answer 4

Ma préférence personnelle est de supprimer le nom de la branche après je suis fait avec un thème de la branche.

Au lieu d'essayer d'utiliser le nom de la branche d'expliquer le sens de la direction générale, je commence à la ligne d'objet du message de commit dans le premier commit sur la branche à Branche:" et contiennent de plus amples 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 se référant à un sujet branche tout en travaillant sur elle. Une fois les travaux sur le thème de la branche a conclu, je m'en débarrasse le nom de la branche, parfois, le marquage de la validation des fins de référence ultérieure.

Qui fait de la sortie de l' git branch plus utiles: elles ne sont que des listes de longue durée de vie des branches et de la rubrique active branches, pas toutes les branches jamais.

Answer 5

Pourquoi faut-il prendre trois branches/fusionne pour chaque tâche? Pouvez-vous expliquer un peu plus?

Si vous utilisez un système de suivi des bogues, vous pouvez utiliser le numéro de bogue dans le cadre de la nom de la branche. Cela vous permettra de garder les noms de branche unique, et vous pouvez préfixer avec un court et descriptif mot ou deux pour garder lisible par l'homme, comme "ResizeWindow-43523". Il contribue également à rendre les choses plus faciles quand vous allez à nettoyer les branches, puisque vous pouvez consulter le bug. C'est de cette façon j'ai l'habitude de nom de mes branches.

Depuis ces branches sont finalement arriver fusionnées en master, vous devriez être sûr de les supprimer après la fusion. Sauf si vous êtes en fusionnant avec d' --squash, toute l'histoire de la direction générale continuera d'exister devrait jamais vous en avez besoin.