0

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!

mitch
  • 396
  • 1
  • 7
  • 14
  • See http://stackoverflow.com/questions/1457103/how-is-a-tag-different-from-a-branch-which-should-i-use-here – jub0bs Jun 02 '16 at 14:17

2 Answers2

3

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.

Nils Werner
  • 34,832
  • 7
  • 76
  • 98
  • Upvoted for easy solution. Concise, makes clear what version the build is based upon, and as you said, collisions are next-to-impossible. – cyberbit Jun 02 '16 at 14:15
  • That looks a lot like the output of `git describe` – 1615903 Jun 03 '16 at 05:29
  • Nice idea. Do you recommend storing that full version number into your code to be built so users can see it? Right now I have a git post-commit hook that puts the commit hash into a file that gets compiled into my build. I could try to format it into the full version number as you have done. Also, does this mean that you only change major, minor, or patch on the master branch (leaving the "build" segment to identify builds that come from other branches)? – mitch Jun 03 '16 at 08:32
  • Also, do you think you lose any benefit by not having a steadily incrementing build number? I like the concept of knowing which build came after which. Or do you cross reference the user back to a table with git hashes to see the history? – mitch Jun 03 '16 at 13:30
  • 1
    Yes, I would only change and tag `x.y.z` when there is an actual release in `master`. Feature and hotfix branches should never change the release numbers themselves. – Nils Werner Jun 06 '16 at 09:51
  • Regarding sequential build numbers: The idea is neat as long as you don't have several branches with work happening in parallel (imagine two customers, each having their requirements implemented in a separate branch). The sequential build number starts losing its meaning as you have two independent build processes both incrementing the number. A commit id on the other hand can immediately be used in `git checkout ` and you see the code that was used. – Nils Werner Jun 06 '16 at 09:58
1

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.

Max Komarychev
  • 2,836
  • 1
  • 21
  • 32
  • Sorry for my ignorance but can you refer me to the CI tool? Is this something you run inside git or as part of your post-build process? – mitch Jun 03 '16 at 13:32
  • 1
    @mitch CI is a "Continuous Integration", usually it is a web app hosted somewhere aside from your git repo and it can be set up to trigger builds whenever you push something to remote repo. CI tool I use in particular is https://jenkins.io. If your process does not involve remote repo or dedicated server with CI you can, of course, write a few scripts for yourself that you can launch manually and that will do things I described (as creating tags, injecting tags into your software etc..) – Max Komarychev Jun 03 '16 at 13:37
  • 1
    @mitch I really meant to write scripts that will combine the deployment process itself with creating tags and stuff like that in a single routine so you will not forget doing something during deployment. – Max Komarychev Jun 03 '16 at 13:48