我非常喜欢NVIE git分支模型，并且一直在尝试采用大多数原则：http://nvie.com/posts/a-successful-git-branching-model/
它并没有真正说出来，但它暗示你应该只标记主分支。这是大多数人在做什么？我问的原因是，我经常从开发分支或功能分支构建一个我想发送给其他人（可信客户或内部测试组）的功能分支。将它合并回主设备没有意义，但似乎有意义的是标记它或以其他方式在其上放置版本号以在进一步测试期间跟踪它，特别是当错误不断被修复并且特征是我们去的时候在各个分支上添加了。
我一直在阅读很多版本编号系统，例如major.minor.patch.build。我可以看到跟踪这些“中间构建”的构建号的一些优点。但是如果我不小心的话，我还可以设想多个分支的多次提交意外地以完全相同的版本号结束。
那么我应该只将标签限制在主分支上吗？如果是这样，我如何跟踪从其他分支发出的版本？
感谢所有输入！
答案 0 :(得分：3)
无需使用标签。相反，您可以使用缩写的Git提交ID：
major.minor.patch.build
然后
3.7.1.b79bbd3
几乎可以保证提交ID不会发生冲突。
答案 1 :(得分：1)
我的规则是标记用于生成远离开发机器的构建工件的每个提交，无论是用于内部测试还是公开发布。你应该更好地在app app / site的UI中的某个地方公开那个标签，这样当你得到错误报告时，你可以通过精确的提交交叉引用它。
例如，master和develop分支的所有更新都会被CI（这些版本用于内部测试）自动标记为build-xxx格式。另外，我为每个上线的版本手动标记master和vX.Y.Z等标记。
<强>更新
关于碰撞的说明：您可以设置CI，以确保所有分支的所有构建标识符都增加1。
如果您不使用CI，则可以将提交的SHA1用作应用程序中向用户公开的构建标识符，在这种情况下，您可以完全跳过使用中间标记并仅使用vX.Y.Z.个
更新2
关于为中间构建创建标记的注意事项：您可能会发现自己有数百个标记，因此为中间短生命构建创建标记可能不是最佳解决方案，在这种情况下使用SHA1会更好，而您将拥有标记对于真正适合生产的稳定版本。
这实际上取决于您正在进行的构建的目的，数量和频率。