A basic understanding in Git is that Tags are aliases to a commit hash (A single entry in the history of commits) whereas a Branch is the name for a diverged chain of commits that share a common history and ancestor. Confusion can be had when assuming a branch is always the HEAD, or most recent, commit in the fork of the code. While this can be true, this is not what a Branch represents and may lead to Tags being used interchangeably with Branches. When Tags and Branches are both used, they give flexibility to teams to share commit history and easily communicate important changes in code, but naming them similarly will lead to collisions if not well thought out.
Take care naming tags and branches to keep from confusing Git
Assume there is a
master branch of code and a
develop branch of code. Daily work is in the
develop branch. Moving code into a
master branch creates a release-able set of code. If the team wishes to be able to maintain the release for any period of time, a Tag should be created at the point in which the code has diverged.
You should never name a tag and a branch the same name!
It makes sense in a case like this to use naming conventions on the tags to keep from colliding on the branch names.
git tag develop-v1.0.0
Versus when we releasing code from the
git tag release/v1.0.0-rc1
git tag release/v1.0.0
You can find the common parent in git using
merge-base to do a Tag on code from the past.
git merge-base branch1 branch2
0f345000facddd090939209dcaef... // etc
If the team is only using
develop collisions with these two branches will be very rare. However, feature branches and release branches bring in much more opportunities.
If a collision has occurred Git will relay that with a message like the following. Assume we have mistakenly created a Tag
release/v1.0.0 and a Branch
release/v1.0.0. What will happen if we tell git to ‘checkout’?
git co release/v1.0.0
By default, git has chosen the Branch. If we meant to ‘checkout’ the Tag, being more specific is required.
git co refs/tags/release/v1.0.0
Notice how we added
refs/tags/. This is what can be found within the
.git folder. The folder structure is the same that is would needed to append. We could also specify
refs/heads/ if we wanted the branch.
At this point, any git command can specific enough check out any branch or tag without “ambiguity”, it’s best to rename the branch by creating a new one and deleting the previous branch; or remove and create a new tag so that the two do not have this collision.