Gitflow: 将发行版错误修复从主分支合并回开发分支

Question

Gitflow: 将发行版错误修复从主分支合并回开发分支

gitgit-flow

4

我的问题围绕gitflow流程中一个非常具体的点（如这里所述）。

我已经将来自release/1.2的错误修复合并到master中，并进行了适当的标记。

除了历史记录的外观之外，从release/1.2回溯合并和从master回溯合并到develop之间有什么区别？

我已经尝试了两种方法，在我的简单且人为的示例中，我在develop中看不到任何差异，正如我所预期的那样。

这样做存在危险吗？我以后会遇到混乱的问题吗？我是否忽略了一些明显的东西？我怀疑答案可能与其他已经进入master但目前应该保留在develop之外的功能有关。

将发行版合并到开发中：

合并主分支到开发分支:

- Denham Coote

你能否包含一个图表来展示你的流程吗？也许那些经常使用Git flow的人可以理解你的描述，但我不行。 - Tim Biegeleisen

@TimBiegeleisen 完成了！ - Denham Coote

4个回答

4

这样做有什么危险吗？以后会遇到问题吗？我有什么显而易见的漏洞吗？

没有危险，没有问题，也没有漏洞。将 master 合并回 develop 是（在我看来）稍微更好的方式，而且没有任何缺点。无论你选择哪种方式，最终在 develop 中都会有相同数量的合并提交。不同之处仅在于这些合并提交进入那里的时间。如果你先将 release 合并回来，直到稍后修复时才会一次性得到所有的 release 到 master 的合并提交。如果你将 master 合并回 develop，你将立即看到最近的合并提交。但是将 master 合并回 develop 还有更大的优势：

始终确保 master 中的所有更改也存在于 develop 或者存在于 release（当它存在时）。（唯一不应该同步的时间是在完成 release 或 hotfix 分支时）。确保 master 已同步的最简单方法可能是确保 master 中的顶部提交总是存在于 develop 或者存在于 release（当它存在时）。你可以轻松地编写脚本以在一定的频率下运行，并在不匹配时通知你。如果不能保证 master 的最新提交总是存在于 release 中，那么该脚本将变得更加复杂。

- TTT

3

我怀疑答案可能与其他已经加入“master”的功能有关，但暂时应该保留这些功能不要加入“develop”。无论如何，“master”中的提交都将随着下一个热修复合并到“develop”中。如果有真正的代码更改，可能会导致意外结果并扭曲热修复内容。

将稳定分支（在gitflow中为“master”）合并到开发分支（在gitflow中为“develop”）是各种git工作流程中已知的方法。Bitbucket Server（Atlassian销售的商业解决方案）具有自动分支合并的功能。Git项目本身总是将分支“maint”合并到“master”中，因为有一些bug修复。

所以我真的看不出为什么gitflow的作者选择了另一种方式。可能是没有真正的理由，只是偶然的决定。

- max630

0

我喜欢这样做，这样在列表视图中看起来就不像主分支领先于开发分支。如果你将主分支合并到开发分支而不是发布分支和热修复分支，那么它将使得主分支永远不会领先于开发分支，在列表视图中，如果它领先了，你就知道出了什么问题，需要进行修复。

- Mark Neisler

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- kowsky · Accepted Answer

如果您将主分支(master)合并回开发分支(develop)，那么您的develop分支中将有所有从版本分支(release/x.y)合并到主分支(master)的合并提交记录，而当合并版本分支(release/x.y)本身时，您只会得到真正的更改。

当然，这或多或少是一个表面问题。但是合并方向通常只能从开发分支(develop)合并到主分支(master)，而不能反过来。

除了合并提交记录混乱外，并没有真正的危险。如果您遵循流程，那么在主分支(master)中不应该有不在开发分支(develop)中的功能，因为热修复以及发布分支都应该合并到您的开发分支(develop)和主分支(master)中。