在svn中,我们曾经使用事后部署挂钩将部署的版本签入号编写为部署的应用程序版本的构建后缀。
即。如果我们正在部署我们的应用程序的3.0版本,应用程序中的about窗口将显示3.0.1234,其中1234是来自svn的构建版本。
这允许QA查看修订版号并查看已解决的错误,比较已解决的错误中的内部版本号,如果部署的应用程序的修订版本高于错误报告中的修订版本,则可以确保已部署修订版本(或不)。
使用git和mercurial,修订哈希不提供类似的功能。你们如何使用git解决这个问题?
答案 0 :(得分:1)
您可以在Git中使用标签上的钩子。标签用于版本控制,以及其他目的。
你甚至可以使用散列本身进行版本控制,例如参见Debian:一些软件包有版本字符串,如4.8.5+git121-g2a9ea11
。为什么不行?
答案 1 :(得分:1)
使用git describe
。输出如下所示:v5.19.5-55-ga854082
,包含三个部分的提交:v5.19.5
是当前分支中最新的标记,55
是自此标记以来的提交数,ga854082
1}}是缩写的SHA1,前面有g
。提交的数量可用于检查是否有更新的东西。
(上面的git describe
输出实际上是来自perl源代码的真实示例)
答案 2 :(得分:0)
我使用post-checkout,post-commit,post-merge和post-rewrite hook:
M=2228.1
rev=`git rev-parse --verify --short HEAD`
b=$(git branch --no-color 2> /dev/null | \
sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/')
case $b in
(_tmp*)
cnt=`git rev-list "$M"..$rev -- | wc -l`
printf '#define AUTO_REVISION TEST%u+%s\n' "$cnt" "$rev" > auto-version.h
...
;;
(*)
cnt=`git rev-list $rev -- | wc -l`
printf '#define AUTO_REVISION g%05u+%s\n' "$cnt" "$rev" > auto-version.h
...
;;
esac
cat << EOF >> auto-version.mk
AUTO_REVISION_CNT = $cnt
AUTO_REVISION_REV = $rev
EOF
'cnt'变量包含自开始以来的提交次数或某个分支/标记(在本例中为2228.1),并且根据实际分支(发布/测试)应用不同的方案。