Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the Git equivalent for revision number?

People also ask

What is the git commit number?

The long string following the word commit is called the commit hash. It's unique identifier generated by Git. Every commit has one, and I'll show you what they're used for shortly. Note: The “commit hash” is sometimes called a Git commit “reference” or “SHA”.

What is head revision in git?

You can think of the HEAD as the "current branch". When you switch branches with git checkout , the HEAD revision changes to point to the tip of the new branch. You can see what HEAD points to by doing: cat .git/HEAD.

Which command is used to add a version number to your git repo?

By using tags: Tags in Git can be used to add a version number. adds a version tag of v1. 5.0-beta to your current Git repository.


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-g2414721

i.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.