Git tag before or after merge?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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