语义版本控制如何融入 git 工作流程答案

【问题标题】：How semantic versioning fits into the git workflow语义版本控制如何融入 git 工作流程
【发布时间】：2012-04-03 23:13:19
【问题描述】：

我目前在 git 中使用语义版本控制时遇到问题。

我们在 http://nvie.com/posts/a-successful-git-branching-model/ 使用 git 版本控制模型

我们还希望遵循http://semver.org/ 中概述的语义版本控制指南

这是我们的一个示例用例。

Release branch: ----1----2----3----4 <- tag v1.2        ----7---8---9 <- tag v1.3
                   /                \                  /             \
Develop branch: --0--------5---------4--6-----------------------------9--

这是我们的示例用例：

发布和开发同时进行开发
发布已准备就绪，我们将其标记为 v1.2。我们为更改 1、2、3、4 生成发行说明。
我们将发布合并回开发。
当我们准备为另一个版本再次开发分支时，我们可以。但是，标签 v1.2 指向 4，因此如果我们查询 v1.2 和 v1.3 之间的更改，5 的发行说明实际上会丢失

我们想要做的是能够搜索所有新添加的签入，因为标签 v1.2 被创建并且新合并到标签 v1.3 中，以便我们可以确定什么样的版本凹凸 (x.y.z)我们需要制作的组件。

如果 5 恰好是重大更改，但从 v1.2 开始的所有内容都不是，我们将错误地更改次要版本，因为签入 5 不在构建中。

有人对如何解决这个问题有任何建议吗？

【问题讨论】：

标签： git versioning

【解决方案1】：

我想这取决于您如何“查询更改”。但是，如果您的意思是使用 git log v1.2..v1.3 或类似的东西，那么它应该准确地向您显示您想要什么，也就是说，包括提交 5。

【讨论】：

如果我们使用 git log v1.2..v1.3，那么提交 5 将被排除，因为 HEAD for develop 将指向提交 4 从版本 v1.2 合并后返回到开发权?因此，提交 5 将在提交 4 之前插入，因此提交 5 本质上将被视为“已覆盖”，因为 HEAD 指向提交 4。
不，真的不会被排除在外。你试过了吗？ v1.2..v1.3 对于 git 表示“v1.3 中的提交，不包括 v1.2 中的提交”，这意味着它将包括 5。
我在一个示例存储库中尝试过，你是对的。谢谢！我的困惑是我正在考虑 HEAD 发布 v1.3 标签而不是 v1.2 到 v1.3。