I have a project with a git branching model that roughly follows that of nvie's git-flow.
Our release branches are named in a SemVer format, e.g. v1.5.2
Once a release branch is given the green light for production, we close the branch, by merging it into master, applying a tag, and then deleting the branch.
As we immediately delete the release branch, we've been using the same identifier for tagging the branch, e.g. v1.5.2
Here's the commands we'd use to close a release branch:
$ 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
This seems to work in the majority of cases, however it's causing an issue in the scenario where another instance of the git repo (e.g. another dev machine, or staging environment) has a local checkout of the v1.5.2 branch.
The git push origin :v1.5.2
command will delete the branch in the remote, but does not delete the local version of the branch (if it exists) in all repos.
This leads to an ambiguous reference, when trying checkout v1.5.2
in those repos:
$ git checkout v1.5.2
warning: refname 'v1.5.2' is ambiguous.
Can this be avoided without using a different syntax for the branches, e.g. release-v1.5.2
, or v1.5.2-rc
?
Or is it unavoidable, and therefore a fundamentally bad idea to create a tag with the same name as a deleted branch?