Voici quelques conventions de dénomination de branche que j'utilise et les raisons de celles-ci
Conventions de dénomination des branches
- Utilisez des jetons de regroupement (mots) au début des noms de vos branches.
- Définissez et utilisez des jetons de plomb courts pour différencier les branches d'une manière significative pour votre flux de travail.
- Utilisez des barres obliques pour séparer les parties de vos noms de branche.
- N'utilisez pas de nombres nus comme pièces principales.
- É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'.
