When using a centralized version control system such as SVN, where every commit acquires an auto-incremented number, it is relatively easy to track what version is released to production by simply setting the version to the identifier of the commit. Version 220.127.116.1122, for instance, matches the 18,522th commit.
With distributed version control systems such as Git, however, the identifiers are hashes, rather than numbers. I can hardly imagine someone on the phone saying: “There is a regression in our version 2F90C275A,” and non-numeric versions don’t play well with some tools, which means that versions are dissociated with the commits: commit 2F90C275A may become version 18.104.22.168, “15” here being the value of an auto-incremented counter in the build tool.
In practice, I find it particularly challenging to find which is the commit of a particular version, and I need to know the mapping to be able to answer a bunch of questions, such as:
- “Is [a given change] that was committed last Friday morning part of the version 22.214.171.124?”
- “What could have broken [a given feature] in version 126.96.36.199?”
- “Let’s do a hotfix. From which commit exactly should we create the hotfix branch?”
If one imagines that the build is done in a way that virtually any commit from the
origin/master can be pushed later on to production, how am I supposed to manage versions properly in order to be able to easily see which version maps to which commit and vice versa?
Go to Source
Author: Arseni Mourzenko