CODEWITHSUNDEEP
gitversion-controlversioning
mitch
mitch

Reputation: 436

Which git branches should I tag?

I really like the NVIE git branching model and have been trying to adopt most of the principles: http://nvie.com/posts/a-successful-git-branching-model/

It doesn't really come out and say it but it implies that you should only tag the master branch. Is this what most people are doing? The reason I ask is that often times I have a build from the develop branch or from a feature branch that I would like to send out for testing to other people (trusted customers or internal test group). It doesn't make sense to merge it back into master yet but it also seems like it makes sense to tag it or otherwise put a version number on it to keep track of it during further testing especially as bugs are continuously being fixed and features being added on various branches as we go.

I've been reading lots about version numbering systems such as major.minor.patch.build. I can see some advantages to keeping track of the build number for these "intermediate builds." But I could also envision multiple commits from multiple branches accidentally ending up with the exact same version number if I'm not careful about it.

So should I limit tags only to the master branch? If so, how do I keep track of the versions that get sent out from other branches?

Thanks for all input!

Upvotes: 0

Views: 110

Answers (2)

Max Komarychev
Max Komarychev

Reputation: 2856

My rule is to tag every commit that is used to produce build artifact that goes away from dev machine, whether this is for internal testing or public release. And you should better expose that tag somewhere in UI of you app/site whatever, so that when you get bug report you can cross reference that with exact commit.

For instance all my updates to master and develop branches are getting tagged automatically by CI (these builds are intended for in-house testing) in format build-xxx. In addition I manually tag master with tags like vX.Y.Z for each build that goes live.

update

A note about collision: you can set up your CI so that all build identifiers are guaranteed to be incrented by 1 across all branches.

If you do not use CI you can use SHA1 of a commit as build identifier that is exposed in your app to a user, in that case you may skip using intermediate tags at all and stick only to vX.Y.Z. ones

update 2

A note on creating tags for intermediate builds: you may find yourself having hundreds of tags, so creating tags for intermediate short-living builds may be not the best solution and in that case using SHA1 would be better while you will have tags for really production-ready stable versions.

This is something that really depends on purpose, amount and frequency of builds you are doing.

Upvotes: 1

Nils Werner
Nils Werner

Reputation: 36765

There is no need to use tags. Instead you could use an abbreviated Git commit ID:

major.minor.patch.build

would then be

3.7.1.b79bbd3

commit IDs are virtually guaranteed to not collide.

Upvotes: 3

Related Questions