一个Bash函数:

git_rev ()
{
    d=`date +%Y%m%d`
    c=`git rev-list --full-history --all --abbrev-commit | wc -l | sed -e 's/^ *//'`
    h=`git rev-list --full-history --all --abbrev-commit | head -1`
    echo ${c}:${h}:${d}
}

输出如下所示

$ git_rev
2:0f8e14e:20130220

这是

commit_count:last_abbrev_commit:date_YYmmdd

使用git散列作为构建号的问题是，它不是单调递增的。OSGi建议对构建号使用时间戳。似乎可以使用向分支提交的数量来代替subversion或强制更改数量。

不管对你来说是好消息还是坏消息，哈希值就是修订号。当我从SVN切换到git时，我也遇到了这个问题。

你可以在git中使用“tagging”将某个修订标记为特定版本的“release”，这样就可以方便地引用该修订。看看这篇博客文章。

要理解的关键是git不能有修订号——想想去中心化的本质。如果用户A和B都提交到他们的本地存储库，git如何合理地分配一个连续的修订号?在他们相互推动/拉动对方的变化之前，A对B一无所知。

另一件需要考虑的事情是用于修复错误的分支的简化分支:

从一个版本开始:3.0.8。然后，在释放之后，这样做:

git branch bugfixes308

这将为错误修复创建一个分支。检查分支:

git checkout bugfixes308

现在进行任何您想要的错误修复更改。

git commit -a

提交它们，然后切换回主分支:

git checkout master

然后从另一个分支中导入这些更改:

git merge bugfixes308

这样，您就有了一个单独的特定于发行版的错误修复分支，但是您仍然将错误修复更改拉到您的主开发主干中。

这是我在基于其他解决方案的makefile中所做的。注意，这不仅为代码提供了一个修订号，还附加了允许您重新创建版本的散列。

# Set the source control revision similar to subversion to use in 'c'
# files as a define.
# You must build in the master branch otherwise the build branch will
# be prepended to the revision and/or "dirty" appended. This is to
# clearly ID developer builds.
REPO_REVISION_:=$(shell git rev-list HEAD --count)
BUILD_BRANCH:=$(shell git rev-parse --abbrev-ref HEAD)
BUILD_REV_ID:=$(shell git rev-parse HEAD)
BUILD_REV_ID_SHORT:=$(shell git describe --long --tags --dirty --always)
ifeq ($(BUILD_BRANCH), master)
REPO_REVISION:=$(REPO_REVISION_)_g$(BUILD_REV_ID_SHORT)
else
REPO_REVISION:=$(BUILD_BRANCH)_$(REPO_REVISION_)_r$(BUILD_REV_ID_SHORT)
endif
export REPO_REVISION
export BUILD_BRANCH
export BUILD_REV_ID

Visual Studio的后构建事件

echo  >RevisionNumber.cs static class Git { public static int RevisionNumber =
git  >>RevisionNumber.cs rev-list --count HEAD
echo >>RevisionNumber.cs ; }

提交的SHA1哈希值相当于Subversion修订号。