要将git版本集成为内部版本号？

我和一个同事轮流讨论/讨论在构建时将从当前git存储库派生的版本集成到我们的代码中的问题/优点。

我们认为优点包括：

• 无需担心人为错误更新版本号
• 我们在设备中找到的内容与源于它的源代码之间的可追溯性

（对我们而言）出现的问题包括：

• IDE派生的构建系统（例如MPLABX）可能很难弄清楚将这些挂钩放置在何处（最终可能会很俗气）
• 实际将其集成到构建脚本/ makefile中的更多工作
• 耦合到特定的构建方法（例如，如果一个人使用XCode和另一个MPLABX进行构建怎么办）可能会给下游带来意外

因此，我们很好奇其他人在这场辩论中的地位。讨论变得容易流传开来。那里有很多人坚持端到端的自动化，把大量的前期工作挂在了一起，并耦合了它带来的影响。辩论的另一端还有很多其他人，他们所做的最简单的事情就是行之有效，并且承受风险。

对于哪一方最好着陆有合理的答案吗？

我们使用git describe和版本标签。流程基本上是：

• 为我们正在使用的版本创建标签（例如v1.1.2）
• 每次运行 git describe
• 发货时，请使用标签名称

git describe提供标签名称，自标签以来的提交次数以及标签的哈希值。样本标签如下所示：

v1.1.2-6-a3b27gae

这样做的好处是开发人员会散列数据，因此，如果在两次构建之间出现中断，则开发人员可以轻松地区分更改。它也很愚蠢，易于管理。只需让您的团队负责创建并在新的bugfix分支上推送标签，然后构建系统就会处理其余的工作。

我们删除哈希（和内部版本号），因为它使用户更容易理解我们的版本号。我们发现这为我们提供了两全其美的优势，同时在设计发行版时仍提供了足够的相关信息。

当前，我们对此有一个稍微复杂的版本，但是这个想法仍然存在。

我们曾经是SVN商店，所以这个数学很容易-内部编号是SVN修订版，仅此而已。当我们开始转向DCVS时，我们试图保持这种状态，发现它由于某些原因而失败。

首先，谁知道版本69bc333bc8d8是在版本25b0f0d1052c之前，之后还是同时出现？与SVN系统相比，当您至少知道101在100之后时，上下文几乎没有。其次，DCVS源代码控制的本质使事情在以后的构建可能不会前进相同的情况下在许多方面呈非线性。

我们最终决定使用构建服务器将构建编号分配给事物，因为它具有正确的可见性和处理能力。

我对C＃DLL的Visual Studio构建系统使用以下方案来自动生成版本号（我们一直以来都存在无法正确执行部署的问题，因此需要一种保证正确部署版本的干净方法）。

• 专业-硬编码1，通常由业务部门确定
• 次要-硬编码0，通常由业务端确定
• 修订-自2010年1月1日以来的天数（或任何其他任意开始日期）
• 内部版本-自午夜以来秒数的一半（因为它是16位无符号数字）

请注意，这是假设您有2个可替代的16位无符号数字一起玩。也可以创建一个使用较小数字的等效系统。

另请注意，如果您可以将非数字字段作为元数据附加，则它们可能会有所帮助。例如，将git版本号添加为信息版本号。

我直接将git status，log和diff的输出链接到可执行文件中。然后有一个选项来打印它。优点是您不仅可以确定二进制文件是从哪个分支生成的，而且还可以包括哪些未提交的源代码更改。请参阅：

https://github.com/colding/MercuryFIX/tree/master/stdlib/scm_state

您应该能够使用这3个文件来制作自己的SCM状态库。

我建议使用Autorevision。

您可以获得各种格式的输出，例如c样式的header。

还有一些示例（在contribs目录中），说明如何进行连接，以便无论是谁构建的以及他们如何执行，即使它们是从tarball构建的，它们也将始终获得相同的版本信息。

另外，由于除了gitAutorevision 以外，它还可以与svn切换，而无需在设置后进行太多更改svn，hg因此更容易。