Git tag before or after merge?
GitGit TagGit Problem Overview
I have a simple question about tagging different versions of my project with git. If I just completed my 1.1 branch and plan to merge it into master, should I tag this branch as 1.1 before I merge it, or should I merge it to master and then tag it as 1.1? Would it make a difference either way? Maybe one way is preferred? Thanks.
Git Solutions
Solution 1 - Git
Depends. Will the branch fast-forward into master?
If the answer is 'yes' then it doesn't matter whether you tag it before or after doing the fast-forward merge, because the tagged commit will be the same either way.
If the answer is 'no', then you should probably tag it after merging into master (assuming you cut releases from master). In general you want your tags to match your releases (to make it easier to look at the version of the code that was released), so you tag the version in the place you're making releases from.
Solution 2 - Git
It all depends on your distribution model. If 'master' is your main release line, I would imagine that 1.1 isn't really 'done' until it successfully merges into the main line, in which case, you should tag after merge.
Note: I've seen some projects use master as a dev branch and then have separate branches for 'stable' versions (not a model that I agree with). In the this case, you tag before merge.
Solution 3 - Git
Agree with the @Amber's answer. (My preferred way)- once you have fast-forwarded merge strategy in place then it doesn't matter where you are tagging your release. one more advantage of this kind of (ff-only) merge strategy is
- You can tag your release (v1.0.1)
- create a pull/merge request to master branch
- set some rules before merging (number of approvals needed before merging to master)
- git graph generated are pretty clean