J'ai un projet avec un modèle de branchement git qui suit à peu près celui du git-flow de nvie .
Nos branches de publication sont nommées dans un format SemVer , par exemplev1.5.2
Une fois qu'une branche de publication reçoit le feu vert pour la production, nous fermons la branche, en la fusionnant dans master, en appliquant une balise, puis en supprimant la branche.
Comme nous supprimons immédiatement la branche de publication, nous utilisons le même identifiant pour baliser la branche, par exemple v1.5.2
Voici les commandes que nous utiliserions pour fermer une branche de publication:
$ git checkout master
$ git merge v1.5.2
$ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc"
$ git branch -d v1.5.2
$ git branch -dr origin/v1.5.2
$ git push origin :v1.5.2
$ git push
$ git push --tags
Cela semble fonctionner dans la majorité des cas, mais cela provoque un problème dans le scénario où une autre instance du dépôt git (par exemple, une autre machine de développement ou un environnement de transfert) a une extraction locale de la branche v1.5.2.
La git push origin :v1.5.2
commande supprimera la branche dans la télécommande, mais ne supprimera pas la version locale de la branche (si elle existe) dans tous les référentiels.
Cela conduit à une référence ambiguë, lors de la tentative d'extraction v1.5.2
dans ces dépôts:
$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Cela peut-il être évité sans utiliser une syntaxe différente pour les branches, par exemple release-v1.5.2
, ou v1.5.2-rc
?
Ou est-ce inévitable, et donc une idée fondamentalement mauvaise de créer un tag avec le même nom qu'une branche supprimée?
git checkout
la balise sera vérifiée sur la branche lorsqu'il y a une référence ambigüe, mais ce n'est pas le comportement que je vois, ref: gist.github.com/tommarshall/9376724 . Est-ce quelque chose qui a changé dans une version plus moderne de git? Existe-t-il un indicateur que je peux définirgitconfig
afin d'obtenir ce comportement?