【发布时间】：2014-11-19 16:50:57
【问题描述】：
我有一个 v1.0 的主分支和一个 v1.1dev 的开发分支。
然后我从 dev 创建一个新的发布分支，并将版本号从 v1.1dev 提升到 v1.1，完成，将所述发布分支合并到 master , presto - v1.1 诞生于master。
然后，我将相同的发布分支合并回 dev，因此 dev 分支也是 v1.1。
虽然这在技术上是正确的，但我觉得 dev 应该总是以 dev 结尾，因为毕竟，它是正在朝着下一个真正版本努力的开发版本。
所以我的问题是：
- 是否每个人都在 dev 分支上专门提交一次提交以在合并到发布分支后提升其 Dec 代码的版本，还是我缺少某些东西（脚本、方法、技术等）？
- 此外，以上描述是否普遍代表人们如何提高版本号？
TL;DR： 在假设语义版本控制的情况下，何时应该在 git 版本化项目的各个分支中增加版本号？
【问题讨论】：
-
视情况而定。你是如何实现版本号的？理论上，版本号的检出应该只包含该版本号的代码，而不是 ++ 版本的代码
-
唯一真正获得标签的分支是master。但我的意思是项目文件中的版本号......你什么时候更新它们？合并release后在dev分支上，还是合并到master后合并到dev之前的release分支上？
-
项目文件中的版本号对开发者来说没有意义。它们仅用于告诉客户他正在运行的软件版本。开发人员应始终参考标签。如果结帐正好在标签上，那么他就有那个版本号。如果它在标签之前，那么他有版本++。这是对“版本”的唯一合理解释。否则两个 2.1 版本的人可能有完全不同的代码。
-
所以在创建发布分支之前，基本上没有开发人员真正关心各种项目文件中的版本号表示什么。对吗？
-
制作一个
v1.1标签。让 git-describe 为 dev 分支生成一个版本号，其中将包含您构建的 HEAD 的缩写散列。不要费心尝试添加-dev后缀；让git-describe为你做吧。
标签： git version-control semantic-versioning