使用git

Question

Subversion的修订版ID在每次提交后递增。我们使用它将它包含在每个版本的版本号中，格式为X.Y.Z，其中X是主要版本，Y是次要版本，Z是版本号。

在我们的问题跟踪器中，我们只需引用subversion修订版号（或在提交消息中引用问题编号），并且很容易确定某个特定版本是否已包含此修复程序。

现在git提交由哈希标识。由于这不能用作版本号，我们使用提交计数代替生成相同的东西，以便在构建期间生成版本号。

现在的问题是，当用户报告错误时，错误报告通常包含版本号，并且很难查找这是否是在更新版本中修复的内容或者是仍未解决，因为使用git我们看到的只是一个提交哈希。

一种解决方案是维护一个转换表，列出每个提交哈希并将其映射到修订号，但这会让生活变得更加艰难。

您能否针对此问题推荐任何最佳做法？

Answer 1

我使用git describe以非常简单的方式处理这个问题。它方便地包装了3条重要的信息：

1. 哈希
2. 最新标签
3. 自最新标记以来的提交次数，以防我们进行无标记提交。

此外，在大多数项目中，我都有标记版本的标准方法：vXXX.YYY.ZZZ。我使用git describe的输出到处都需要对提交的确切引用。例如，我的一个项目是：

v1.1.9-19-g3024adf

我通常运行一个预编译脚本，在一些编译器符号中注入它以包含在二进制文件中。使用标准方法命名我的标签可以确保我在git describe的输出上得到一个上限长度，这对我来说很重要，因为我需要在嵌入式系统中包含的任何协议中使用它。

Answer 2

不要使用提交计数。只需包含哈希的前几个字符代替旧版本号。您不需要包含整个字符串，前五或六个字符就足够了。

版本号在分布式上下文中没有意义，因为历史记录显然不是线性的。什么是提交10对你来说可能是对别人克隆的完全不同的提交。

Answer 3

所以，有一个概念性的问题（虽然SVN使这成为可能，但手工工作更多）git强调合并的不同分支。

所以我们假设

     /--> B1 --> B2 --> … --> B18-\
A -->                              +--> D
     \--> C1 --> C2 --------------/

D应具有哪个版本号？它是version(A) + 19（上部路径）还是version(A) + 3（下部路径）？或者您将合并计为修订版（+1计数）？

所以，即使在SVN时代，你的单调修改基本上只是一个约定，你可能并没有真正在除了trunk之外的分支上工作，如果从那个数字你可以看到修复是否存在。

单分支方案对于团队中的现代开发或使用允许您构建功能的系统没有任何意义，而不必在另一个分支中摸索您的错误修正。因此，仅仅是将一个分支声明为“版本化”分支的惯例，通常只需要一个“主”分支（这是git中的默认分支），其中所有功能分支在它们工作时立即合并，每当有人想要处理新功能时，就会从中分叉出新的功能分支。然后，只要发生重大事件，你就会在主分支上提交git tag - 例如，新版本。典型的标签名称为release_001_002_001。是的，它是手动的，与SVN上的自动修订计数相比，但它不同于实际对您的代码管理有用 - 查找某个错误修正提交哈希是否发生在另一个提交哈希之前或之后只是{{1}的问题}。

您实际上只需计算 git log和A之间的提交。然后，D将是version(D)。这是相对可行的;你是

version(A) + 18 + 2 + 1

同样，我怀疑这是否有用。

Answer 4

正如我在评论中所说，问题归结为线性化。如果您想要一个简单的递增计数来指定某个特定的提交，那么必须有一个使这个简单的递增计数的源点。

在SVN中，有一个显而易见的地方：所有提交都存储在主中央服务器上。为了进行 new 提交，您调用中央服务器并说：进行新的提交。这要么成功 - 并且可以获得一个简单的递增数字 - 或者它失败并且没有提交。

在Git中，没有指定的中央服务器。每个开发人员都会自己提交。提交在同行之间交换。任何给定提交的全局唯一标识符是它的哈希：Git保证没有两个提交具有相同的哈希。 ¹

缺少单个中央计数点会破坏自己进行简单修订计数的有用性，因为不同的存储库可以并且将具有相同的数量提交而不包含相同的 set < / em>的提交。我可能有17个提交，其中2个与你的17个提交不同，所以如果我们合并我们的两个存储库，我们最终都会提交19个提交。 （如果我把你和我的结合起来，我会得到19个提交 - 我从你那里获得的两个新提交，加上我们已经共享的15个 - 当你还有17个时：你仍然必须接受我缺少的两个提交。）< / p>

然而，您可以使用您的想法：只需指定一个中央计数点：

  

一种解决方案是维护一个转换表，列出每个提交哈希并将其映射到修订号，但这会让生活变得更加艰难。

例如，如果在＆＃34; release-build＆＃34;上进行了任何发布构建。系统，发布 - 构建系统有一个Git存储库，你只需指定其存储库作为中心计数点。

它维护着桌子。 count 可能是其存储库中的提交次数。 ² 但这比我们需要的还多：计数可以简单表中的条目数;没有必要计算非构建版本。在任何情况下，来自＆＃34; count＆＃34;的翻译通过在表格中查找或添加适当的条目来完成＆＃34;哈希＆＃34;，反之亦然。

此简化计数的值充其量是可疑的。查看真正的软件版本，这些版本通常标有＆＃34;点缀版本＆＃34;：Git版本2.8.4，Git版本2.9.0，Git版本2.10.1; Python 2.7.12，Python 3.4.5等。 7.3.12如何与7.4.0比较？它是严格的＆＃34;小于＆＃34;还是不？使用Git，在构建版本时，您可以使用这样的虚线版本标记它们。标签可以使用Git的内置机制进行分发，每个人都可以在本地查找v7.3.12并查找提交。如果您没有该标记，则可能没有该版本：您必须git fetch，可能还有--tags来自某人。

标签实际上是此中央映射表的分布式版本。但是，我们只使用名称vX或vX.Y或其他任何名称来代替计算标记。

这些标签可以使用git describe进行扩展，这可以让您说出这个固定标签远离这么多提交，加上一个独特的验证器/定位器，以防分布式构建使相对计数中断。＆＃ 34;请参阅Sébastien Dawans' answer。

¹ 这个＆＃34;保证＆＃34;通过一个简单的机制保存：如果两个提交做具有相同的哈希，Git只是拒绝相信第二个存在。它不会接受它，它不会将它存储到存储库中，并且现有的哈希值会赢得＆＃34;。对于任何给定的对象，这种情况发生的可能性很小：2个 ^N 中的一个，其中N是散列中的位数。由于Git使用的是160位的SHA-1，所以2 ^-160 。

由于所谓的生日悖论或birthday problem，概率随着物体的数量迅速增加。然而，我们从如此小的基础开始，我们可以拥有数万亿个对象，可能多达1.7千万亿左右，然后机会甚至上升到与未检测到的存储介质损坏的机会相同的水平。 （此处的名称使用＆＃34;短标度＆＃34 ;;请参阅https://en.wikipedia.org/wiki/Quadrillion。）

² 如果你做使用这种方法（计算其存储库中的提交次数），你必须确保你从不删除任何提交，或者计数会下降，因此不会像升序功能那样。这是表条目计数可能更好的一个原因;或者您可以使用一个永远不会重置的单独计数器，在选择下一个数字时使用原子获取和增量。