Simulating a global revision number with git

How would I go about simulating a global increasing revision number for every commit in the git main line?

So, after I commit I would like a script to run increases a number somewhere.

This will allow me to tell my customers easily that X feature was fixed in git revision XYZ.

开发者_Python百科I am looking for a practical sample script that is robust enough to handle pushes and merges to a degree.

---

git describe gives you a version description like the following: v2.0-64-g835c907. The v2.0 part is the name of the latest annotated tag preceding the commit, 64 is the number of commits after that, and 835c907 is the abbreviated commit id. It is basically there to identify any revision in an exact and convenient (although technical) way.

Note: For this to work you will need at least one annotated tag. To create one for version v2.0 run - git tag -a v2.0, if you have no annotated tags this command will fail, unless given a fallback argument like --tags or --always.

---

It's possible to simulate a revision number in git, however it's important to know that it's not a perfect match and not the easiest to trace back to. Personally I use it to make more simple revision numbers for a web app because I'm the sole developer. I use the following function in my .bashrc to get the revision number which I then use for the release notes (however if you aren't already I highly recommend tagging the release - then the number is just for users). If the limitations are well known it gives a much more human friendly revision number.

function rgit() {
    git rev-list --abbrev-commit HEAD | wc -l | awk '{print $1}'
}

---

I think you're confusing revision numbers with release numbers.

Subversion uses revision numbers because it can: it's a centralized repository. Git of course has SHA-1 hashes not revision numbers because it has no central repository (but you know this).

That revision number (and the hash is technically a 160 bit number, it's just not sequential) shouldn't really be of concern to your customers. What they should be concerned with is the release number. That's when you package up your source code and say "this is version 2.3.4", complete with release notes to say what's changed.

Ideally such a list is generated by issue-tracking software and your source code is simply tagged to say which revision constitutes that release number.

---

I (being unaware of git describe) have been using the following script:

#!/bin/bash

FULL_BRANCH=`git branch | grep '*'`
BRANCH_NAME=${FULL_BRANCH:2}
REV=`git rev-parse --short HEAD`

$COMMIT_NAME = $BRANCH_NAME-$REV

This gives you a name that contains the current branch name, followed by the short commit ID. For example: master-c03f862.

It is enough to do what you are after, but perhaps git describe is the correct way to go here.