What is the Git equivalent for revision number?
With modern Git (1.8.3.4 in my case) and not using branches you can do:
$ git rev-list --count HEAD
68
But this has all kinds of issues and might not be easy to reproduce or easy to get back to the commit hash in case you need to. So try to avoid it or use it only as a hint.
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:
git branch bugfixes308
This will create a branch for bugfixes. Checkout the branch:
git checkout bugfixes308
Now make any bugfix changes you want.
git commit -a
Commit them, and switch back to the master branch:
git checkout master
Then pull in those changes from the other branch:
git merge bugfixes308
That way, you have a separate release-specific bugfix branch, but you're still pulling the bugfix changes into your main dev trunk.
The git describe command creates a slightly more human readable name that refers to a specific commit. For example, from the documentation:
With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent v1.0.4-14-g2414721i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.
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".
The other posters are right, there is no "revision-number".
I think the best way is to use Tags for "releases"!
But I made use of the following to fake revision numbers (just for clients to see revisions and the progress, as they wanted to have the same increasing revisions from git as they where use to by subversion).
Show the "current revision" of "HEAD" is simulated by using this:
git rev-list HEAD | wc -l
But what if the client tells me that there is a bug in "revision" 1302 ?
For this I added the following to the [alias] section of my ~/.gitconfig:
show-rev-number = !sh -c 'git rev-list --reverse HEAD | nl | awk \"{ if(\\$1 == "$0") { print \\$2 }}\"'
using git show-rev-number 1302 will then print the hash for the "revision" :)
I made a Blog Post (in german) about that "technique" some time ago.
Git does not have the same concept of revision numbers as subversion. Instead each given snapshot made with a commit is tagged by a SHA1 checksum. Why? There are several problems with a running revno in a distributed version control system:
First, since development is not linear at all, the attachment of a number is rather hard as a problem to solve in a way which will satisfy your need as a programmer. Trying to fix this by adding a number might quickly become problematic when the number does not behave as you expect.
Second, revision numbers may be generated on different machines. This makes synchronization of numbers much harder - especially since connectivity is one-way; you may not even have access to all machines that has the repository.
Third, in git, somewhat pioneered by the now defunct OpenCM system, the identity of a commit (what the commit is) is equivalent to its name (the SHA id). This naming = identity concept is very strong. When you sit with a commit name in hand it also identifies the commit in an unforgeable way. This in turn lets you check all of your commits back to the first initial one for corruption with the git fsck command.
Now, since we have a DAG (Directed Acyclic Graph) of revisions and these constitute the current tree, we need some tools to solve your problem: How do we discriminate different versions. First, you can omit part of the hash if a given prefix, 1516bd say, uniquely identifies your commit. But this is also rather contrived. Instead, the trick is to use tags and or branches. A tag or branch is akin to a "yellow stick it note" you attach to a given commit SHA1-id. Tags are, in essence, meant to be non-moving whereas a branch will move when new commits are made to its HEAD. There are ways to refer to a commit around a tag or branch, see the man page of git-rev-parse.
Usually, if you need to work on a specific piece of code, that piece is undergoing changes and should as such be a branch with a saying topic name. Creating lots of branches (20-30 per programmer is not unheard of, with some 4-5 published for others to work on) is the trick for effective git. Every piece of work should start as its own branch and then be merged in when it is tested. Unpublished branches can be rewritten entirely and this part of destroying history is a force of git.
When the change is accepted into master it somewhat freezes and becomes archeology. At that point, you can tag it, but more often a reference to the particular commit is made in a bug tracker or issue tracker via the sha1 sum. Tags tend to be reserved for version bumps and branch points for maintenance branches (for old versions).