语义版本控制和 git 分支 [关闭]

Posted 2023-03-07

【中文标题】语义版本控制和 git 分支 [关闭]

【英文标题】：Semantic versioning and git branches [closed]

【发布时间】：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为你做吧。

【参考方案1】：

虽然现在这对你来说可能不再是问题，但你说得对：

...始终是开发版本正在朝着下一个方向努力 真实版...

分支代码时，将分支版本保留为 v1.0。这将是发布分支，即进入此版本的代码库，如果用户无法升级到下一个完整版本，则在将来必须修复错误或增强此版本时，您可以修补它。

您始终可以将该分支中的更改合并回 master，但显然不能有任何定义版本号的代码，通常无论如何都在配置、属性或构建文件中。

分支后，将 master 中的版本提升到 v1.1.x 或 v1.1-DEV 或任何您喜欢的名称。