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


1121

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.)


Oui - probablement bon de ne pas rester ou de pousser les branches qui ne sont pas utiles une fois que vous en avez terminé. À moins qu'il n'y ait une bonne raison de conserver une branche de sujet (par exemple, pour la consulter plus tard), il n'y a aucun problème à la supprimer. Git facilite les branchements, et un corollaire est que vous pouvez vous retrouver avec beaucoup de branches triviales qui peuvent être nettoyées sans trop de bruit.
Eric Walker


2
Pour être complet, il existe certaines séquences de caractères que vous ne pouvez pas utiliser .
Nick Westgate

18
Il doit y avoir une place pour ce type de questions au sein du réseau StackExchange. Très énervant et ennuyeux quand quelqu'un pose une bonne question comme celle-ci, puis elle se ferme pour ne pas suivre les règles. Si cela continue, cela devrait probablement signaler la nécessité de soutenir ce genre de questions d'une manière ou d'une autre. Seulement, ceux-ci devraient probablement être implémentés dans le site Overflow car ils sont si étroitement liés aux questions de type programmation. Le débordement, pour moi, n'est pas pour les «questions objectivement répondables» (trop spécifiques), c'est «les questions de programmation».
Nick Res

@Wim Nous utilisons des clés d'émission jira, combinées avec un titre court, par exemple:KEY-1234/allow-users-to-do-smart-stuff
RobAu

Réponses:


938

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'.


156
Un inconvénient de l'utilisation d'un mélange de formulaires comme bug/20574/frabnotz-finderet bug/20424c'est qu'une fois que vous commencez sans sous-jeton, vous ne pouvez pas en ajouter un plus tard et vice versa. EG: Si vous créez une bug/20424branche, vous ne pouvez pas créer de bug/20424/additional-fixingbranche plus tard (sauf si vous supprimez la bug/20424branche). De même, si bug/20574/frabnotz-finderest déjà une branche, vous ne pouvez pas créer de bug/20574branche. J'ai tendance à utiliser un délimiteur sans sous-jeton dans des cas comme celui-ci (par exemple bug/20574_frabnotz-finder), ou à choisir un nom par défaut pour le sous-jeton (par exemple bug/20424/main).
Slipp D. Thompson

5
Il présente également l'avantage d'inviter certains outils basés sur l'interface graphique Git à autoriser la réduction des divisions de jetons comme une vue de liste de répertoires. Dans l'exemple ci-dessus, vous verriez un featuregroupe et un buggroupe, extensibles pour afficher foo, des barbalises pour le premier et un 20574, des 20592groupes et 20424, des 21334balises pour le second.
Slipp D. Thompson du

47
Je vais lancer une campagne pour ne jamais utiliser de barres obliques dans la dénomination de branche git. La raison en est que si sur un CI par exemple, vous voulez faire référence au nom de la branche lors du conditionnement du code par exemple, vous voulez vous référer au nom de la branche lors de la construction d'un uri ou PATH (par exemple), peut-être en construisant un uri dans un script bash; vous aurez du mal à créer l'URI en raison de la barre oblique ajoutant une partie d'URL. Oui, il est possible de remplacer la barre oblique, mais cela va me prendre beaucoup de temps pour trier.
Adam Spence

13
Est-ce un problème que les barres obliques aient un sens pour git dans certains cas? Par exemple, en réponse à git branch -a, et obtenir remotes/origin/master, etc. Quand je vois git me parler d'une branche, je n'utilise pas de barres obliques et donc quand j'en vois une, je sais que c'est une référence "spéciale".
Dogweather

11
Pourriez-vous utiliser quelques exemples au lieu de foo et bar s'il vous plaît?
Worthy7

329

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.

entrez la description de l'image ici


129
Sauf que cela ne répond pas vraiment à la question, car cela laisse un tas de conventions de dénomination à l'utilisateur, en particulier pour les branches de fonctionnalités (elles peuvent être "tout sauf master, develop, release- ou hotfix- "
Brian

1
@Brian À quoi une convention de dénomination de fonction pourrait-elle aider dans le contexte des problèmes que le modèle résout? Je ne vois pas vraiment, actuellement, comment faire de nouvelles distinctions dans les fonctionnalités aide vraiment. Peut-être future vs prochaine version, mais c'est négociable et ne devrait donc pas faire partie du nom. Pour plus de lisibilité, il suffit peut-être de les ajouter avec feature- *. Vous vous êtes levé voté plusieurs fois, donc je suis juste curieux d'entendre votre réflexion ...
Nick Res

2
Bien que de bonnes informations, cette réponse aborde la question du flux plutôt que la convention de dénomination. Je pense que l'OP aimerait savoir quels mots réels utiliser (noms vs verbes), délimiteurs, cas etc.
Caltor

6
Le livre Continuous Delivery (p. 36) soutient que ce modèle est une sorte d'antithèse de l'intégration continue, ... essentiellement, il n'est pas vraiment "agile".
Markon

Cela ne répond pas réellement à la question posée. Cela offre un aperçu de l'intégration d'un flux de travail git spécifique dans un calendrier de développement et de publication global, cependant, l'op cherche des conseils sur les conventions sur ce qu'il faut réellement appeler les branches.
wheeler

56

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.


53

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.


Je suis le même, sauf le numéro de bogue / fonctionnalité dans le message de validation (pour GitHub -> intégration Pivotal Tracker).
Leo

Je me demande ce que RSSI signifie.
Renshuki

@renshuki c'est juste une clé de projet générique Jira. Quel que soit le problème que vous utilisez, insérez l'ID de ticket
MikeG

@MikeG merci pour la précision!
Renshuki

3
J'utilise la même chose, sauf que je passe le numéro de problème avec la description:name/feature/issue-tracker-number-short-description
lephleg

22

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.


12

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.


7

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


1
Y a-t-il un problème avec les conflits? Si l'intention est qu'une v1.2.4branche mène finalement à un point final avec une v1.2.4balise (ai-je raison de supposer que c'est la situation où vous nommez à la fois des branches et des balises après une version) , alors est-ce important? La balise peut toujours être atteinte à refs/tags/v1.2.4et la branche à refs/heads/v1.2.4, et il semble que Git préfère le nom de la balise lorsqu'il est ambigu (avec un avertissement).
Slipp D. Thompson

1
Pour l'exemple de version, comme je l'ai mentionné dans ma réponse, une pratique suggérée est de préfixer avec "v" pour les noms de balise, pas les branches. Évitez toute ambiguïté si vous le pouvez pour éviter les problèmes de communication et parce que cela pourrait causer des problèmes lors de la migration vers le VCS le plus récent et le plus performant.
Gary S. Weaver

2
J'ai récemment travaillé avec un référentiel où nous avons plafonné chaque branche de version avec une balise du même nom. Cela a très bien fonctionné car il n'y a pas ou peu d'ambiguïté (le tag pointe vers le dernier commit sur la branche correspondante dans la plupart des cas), et quand il pourrait y en avoir, Git "fait la bonne chose" (avec un avertissement). Je le préfère parce que si quelqu'un fait une erreur stupéfiante et s'engage plus loin dans une branche plafonnée, Git continuera de choisir la balise, ce qui est l'intention. L'ambiguïté peut simplifier les choses lorsque le système a tout sous contrôle et que l'intention est claire.
Slipp D. Thompson
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.