We use SVN at work, but for my personal projects I decided to use Git. So I installed Git yesterday, and I wonder what is the revision number equivalent in Git.
Let's say we work on version 3.0.8 and every bug fix has its own revision number we can use when we talk about this bug fix. So if I tag the code in Git to 3.0.8 what then I can use as a revision number or some other more detailed kind of identification? I find the hash not so user friendly for humans.
Good or bad news for you, that hash IS the revision number. I also had trouble with this when I made the switch from SVN to git.
You can use "tagging" in git to tag a certain revision as the "release" for a specific version, making it easy to refer to that revision. Check out this blog post.
The key thing to understand is that git cannot have revision numbers - think about the decentralized nature. If users A and B are both committing to their local repositories, how can git reasonably assign a sequential revision number? A has no knowledge of B before they push/pull each other's changes.
Another thing to look at is simplified branching for bugfix branches:
Start with a release: 3.0.8. Then, after that release, do this:
This will create a branch for bugfixes. Checkout the branch:
Now make any bugfix changes you want.
Commit them, and switch back to the master branch:
Then pull in those changes from the other branch:
That way, you have a separate release-specific bugfix branch, but you're still pulling the bugfix changes into your main dev trunk.
The problem with using the git hash as the build number is that it's not monotonically increasing. OSGi suggests using a time-stamp for the build number. It looks like the number of commits to the branch could be used in place of the subversion or perforce change number.
For people who have an Ant build process, you can generate a version number for a project on git with this target:
The result looks like this:
The dirty flag is here when you have file(s) not committed when you generate the version number. Because usually, when you build/package your application, every code modification has to be in the repository.
The
git describe
command creates a slightly more human readable name that refers to a specific commit. For example, from the documentation:As long as you use sensibly named tags to tag particular releases, this can be considered to be roughly equivalent to a SVN "revision number".
I wrote some PowerShell utilities for retrieving version information from Git and simplifying tagging
functions: Get-LastVersion, Get-Revision, Get-NextMajorVersion, Get-NextMinorVersion, TagNextMajorVersion, TagNextMinorVersion:
If you're interested, I managed version numbers automatically from git infos here under the format
where build is the total number of commits. You'll see the interesting code in the
Makefile
. Here is the relevant part to access the different part of the version number: