我们使用这个命令从git中获取版本和修订:

git describe --always --tags --dirty

它返回

当没有使用标记时提交哈希作为修订(例如gcc7b71f) 当标签上的标签名称为版本时(例如v2.1.0，用于版本) 标签名称，自上一个标签以来的修订号，以及在标签之后提交哈希(例如v5.3.0-88-gcc7b71f) 如果工作树有局部修改(例如v5.3.0-88-gcc7b71f-dirty)，则与上述相同，加上“dirty”标签。

参见:https://www.git-scm.com/docs/git-describe#Documentation/git-describe.txt

每个提交都有一个唯一的散列。除此之外，git中没有修订号。如果您想要更加用户友好，就必须自己标记提交。

一个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

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

git describe命令创建一个更容易读懂的名称，用于引用特定的提交。例如，从文档中:

和像少年犯一样的东西。git当前树，我得到: [torvalds@g5 git]$ git描述父 v1.0.4-14-g2414721 例如，我的“父”分支的当前头基于v1.0.4，但由于它在此之上有一些提交，describe在最后添加了额外提交的数量(“14”)和提交本身的缩写对象名称(“2414721”)。

只要您使用合理命名的标记标记特定的版本，就可以认为这大致相当于SVN的“修订号”。