如何使用 Git 的 `describe` 命令派生应用程序构建版本字符串？

Posted 2023-02-22

【中文标题】如何使用 Git 的 `describe` 命令派生应用程序构建版本字符串？

【英文标题】：How to derive application build version string with Git's `describe` command?

【发布时间】：2011-03-19 01:30:12

【问题描述】：

我想编写应用程序构建版本，该版本自动派生自我所在的 Git 分支名称（构建时）以及分支发生分歧后的提交次数。我相信这对于我的 Git 存储库中的任何提交都是独一无二的？分支名称是唯一的，并且提交沿分支相互链接？如果当我标记一个提交时，我也可以让版本以该标记为前缀。

在某种程度上git describe 做了我想要的，但它不包括我所在的分支名称，它包括缩写的提交 SHA-1 哈希，我认为我不需要它，因为它没有添加任何东西到字符串的熵，可能是多余的（我这里可能错了，请纠正我）。

我有哪些选择？我在想正确的方向吗？当我在软件开发方面有更重要的事情要处理时，我只是有点厌倦了在版本上附加数字。

顺便说一句，我从不使用肮脏的工作树进行构建。 IE。我总是在构建公开版本之前提交对存储库的更改。

【参考方案1】：

关于 git，您需要了解的是，分支本质上只是提交书签。当您进行0deadbeef 提交时，您在foo 分支上这一事实对提交本身并不重要；分支不是其身份的一部分。

（Mercurial 将分支名称烘焙到提交中。In a variety of ways, this is inferior, as Dustin Sallings explains。）

即使假设git describe 只会使用当前签出的分支——如果你有合并历史，可能会有多个路径指向git describe 将使用的同一个最新标记提交。所以甚至不一定有任何一个分支。

另一个注意事项：您可能会反对，即使“来自标记 X 的第 3 次提交”在一般情况下是模棱两可的，git describe 可以只查看图表并确定它是否 模棱两可并且如果没有，请忽略哈希。然而，没有什么能阻止任何人稍后在该标记之上开始一个分支 - 所以你的 describe 字符串将变得模棱两可追溯。

底线是提交的唯一明确标识符是它的哈希。所以那一定在里面。 git describe 所做的是添加一些冗余（在提交号的情况下是模棱两可的）信息，使描述对人类定位自己的空间/关系理解更有用，在Git 模型的限制。

【讨论】：

是的，我现在已经意识到了分支的这个属性。有了它，确实要指定一个分支是模棱两可的。

【参考方案2】：

这是我使用的：

echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"

它会产生类似的东西：

master-6de772e

正如亚里士多德所指出的，实际上 SHA-1 本身就足以提供明确的构建标签以及有关发展历史背景的完整信息。其他一切都是多余的，因为它们提供的任何信息都可以从 SHA-1 中计算出来或派生出来。然而，人类可能也喜欢直接明显的实际分支的补充上下文信息（或者，至少这个人喜欢），因此将分支名称嵌入标签中。出于这个原因（即即时人工解析信息），我的大多数项目还使用更长的构建标识“描述”，除了构建标识“标签”之外，还包括构建所基于的提交的日期和时间' 上面给出的。

【讨论】：

好吧，鉴于我认为我所要求的可能根本不可能，我将不得不求助于缩写哈希。顺便说一句，我不需要分支名称。

@jeet 你能说一下如何在make文件中包含它吗？我试过 '@echo (your-answer) > git-version.h' 但这不起作用

@Denis 我使用自动构建，所以 Makefile.am 看起来像这样：github.com/jeetsukumaran/Ginkgo/blob/master/ginkgocc/…

【参考方案3】：

正式版本应该有一个带有版本号的标签。 在这种情况下，我建议采用以下方法：

如果当前提交有标签，则使用该标签 如果没有可用的标签，请使用分支名称和 SHA1-key

这个命令应该可以工作：

git describe --exact-match 2> /dev/null || echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"

【参考方案4】：

git describe --long 总是会像这样输出版本号：v1.2-10-gdeadbee，这意味着自 annotated 标签“v1.2”指向后的第 10 次提交在提交时使用缩短的 SHA-1 'deadbee'。所以你所要做的就是标记分支开始（分支的分支点），例如&lt;<em>branch</em>&gt;-start.

需要缩写的提交 SHA-1 哈希来区分模棱两可的情况，因为“3rd commit since tag 'x'”（例如）不能唯一区分提交；在存在非线性、分支开发的情况下，可能有多个提交符合上述描述。例如，在下面的 ASCII-art 图所示的情况下，标有 * 的两个提交都符合“自标签‘x’以来的第 3 次提交”描述。

/-.---*---.-\ / \ .---x---.---.---*---.---M---。

_{请注意，在如上所示的“合并”情况下，您不能使用分支名称来区分具有相同描述的两个提交。}

所以你要做的就是获取git describe --long 输出（--long 选项在这里是为了避免解析的歧义，请参阅git describe manpage），解析它，并添加当前分支信息（来自例如@987654326 @，不是来自自己的 git branch 输出）。

【讨论】：

我很清楚“自第 N 点以来的第三次提交”会模棱两可，这就是为什么我要问是否存在分支名称会消除歧义。在上面的示例中，两者确实都是第 3 次提交，但它们位于不同的分支上。因此，一个可以描述为 v1.2-10-A 和另一个 v1.2-10-B，其中 A 和 B 是分支名称。这就是我很好奇的地方。

@amn：不在“合并”的情况下，分支名称无济于事 - 请参阅修改后的图表。分支是短暂的。

嗯，从“其他”分支合并的“M”在主分支上（我猜合并是在“主”上使用“git merge other”完成的），所以它仍然可以在分支“master”上唯一标识为第 7 次（初始提交是第 1 次）提交，不是吗？我错过了什么吗？你能提供一个真正崩溃的例子吗？

@amn：问题不是'M'，而是图表上标记为'*'的提交，两者都是“自标签'x'以来的第3次提交”（或“从头开始的第5次，将初始提交计为 1st")，并且两者都在分支 'master' 上。

Jakub，即使标有 * 的两个提交都是标签 x 的第三个，它们位于不同的分支上。顺便说一句，我从来没有说过我想从标签中计数，我说过如果需要我可以在标签前面加上版本。