我想编写应用程序构建版本，该版本自动从我所在的 Git 分支名称（构建时）和分支分歧后的提交次数派生。我相信这对于我的 Git 存储库中的任何提交都是独一无二的？分支名称是唯一的，并且提交沿分支相互链接？如果并且当我标记提交时，我还可以让版本以该标记为前缀。
在某种程度上git describe做了我想要的，但它不包括我所在的分支名称，它包括缩写的提交 SHA-1 哈希，我认为我不需要它，因为它不会向字符串的熵添加任何内容并且可能是多余的（我在这里可能错了，所以请纠正我）。
我有哪些选择？我在想正确的方向吗？当我在软件开发方面有更重要的事情要处理时，我只是有点厌倦了在版本上附加数字。
顺便说一句，我从不使用肮脏的工作树进行构建。即，我总是在构建公共版本之前提交对存储库的更改。
关于 git，您需要了解的一点是，分支本质上只是提交书签。foo提交时您在分支上的事实0deadbeef对提交本身无关紧要；分支不是其身份的一部分。
（Mercurial 将分支名称烘焙到提交中。正如 Dustin Sallings 解释的那样，从各种方面来说，这是次要的。）
即使假设git describe它只使用当前签出的分支——如果你有合并历史，可能会有多个路径通向相同的最近标记提交git describe。所以甚至不一定有任何一个分支。
另一个注意事项：您可能会反对，即使“标签 X 的第 3 次提交”在一般情况下是模棱两可的，git describe也可以只查看图表并确定它是否模棱两可，如果不是，则忽略散列。但是，没有什么可以阻止任何人稍后在该标签上开始一个分支 - 所以你的字符串会在追溯describe时变得模棱两可。
底线是提交的唯一明确标识符是它的哈希。所以那一定在里面。git describe所做的是添加一些冗余（在提交号的情况下是模棱两可的）信息，使描述对人类在 Git 模型范围内定位自己的空间/关系理解更有用。
这是我使用的：
echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"
它产生类似的东西：
master-6de772e
正如亚里士多德所指出的，实际上 SHA-1 本身就是提供明确的构建标签以及有关发展历史背景的完整信息所必需和充分的一切。其他一切都是多余的，因为它们提供的任何信息都可以从 SHA-1 中计算出来或派生出来。然而，人类可能也喜欢直接明显的实际分支的补充上下文信息（或者，至少，这个人喜欢），因此将分支名称嵌入标签中。出于这个原因（即立即人工解析信息），我的大多数项目还使用更长的构建标识“描述”，除了构建标识“标签”之外，还包括构建所基于的提交的日期和时间' 上面给出的。
正式版本应该有一个带有版本号的标签。在这种情况下，我建议采用以下方法：
这个单一的命令应该工作：
git describe --exact-match 2> /dev/null || echo "`git symbolic-ref HEAD 2> /dev/null | cut -b 12-`-`git log --pretty=format:\"%h\" -1`"
git describe --long总是会像这样输出版本号：v1.2-10-gdeadbee，这意味着自注释标记“v1.2”指向带有缩短的 SHA-1“死蜂”的提交以来的第 10 次提交。因此，您所要做的就是标记分支开始（分支的分支点），例如.<branch>-start
需要缩写的提交 SHA-1 哈希来区分模棱两可的情况，因为“3rd commit since tag 'x'”（例如）不能唯一区分提交；在存在非线性、分支开发的情况下，可能有多个提交符合上述描述。例如，在下面的 ASCII-art 图所示的情况下，标有 * 的两个提交都符合“自标签‘x’以来的第 3 次提交”描述。
/-.---*---.-\
/ \
.---x---.---.---*---.---M---。<--- 分支
请注意，在如上所示的“合并”情况下，您不能使用分支名称来区分具有相同描述的两个提交。
所以你要做的就是获取git describe --long输出（--long这里的选项是为了避免解析的歧义，请参阅git describe manpage），解析它，然后自己添加当前的分支信息（来自 eg git symbolic-ref HEAD，而不是来自 pasing git branchoutput ）。