GitFlow在热修复完成时将主分支中不需要的方面合并到开发分支上。

Question

我们正在使用GitFlow，采用一个相当标准的设置，其中我们有：

• Master代表最新生产版本
• develop代表正在进行的开发
• hotfixes / x下的一些热修复代表正在进行的错误修复
• features / x下的一些特性代表下一个版本中正在进行的更大的特性。

我们在develop和master之间有一些差异，例如我们希望master指向某些NuGet依赖项的特定版本，而develop则指向这些依赖项的其他版本。

我们发现，当我们执行GitFlow Hotfix并尝试完成该hotfix时，在从hotfix分支合并到develop的过程中，它将尝试将这些配置差异从master合并到develop，即使这些配置更改不是作为hotfix的一部分完成的。

我的同事断言，这个问题可能是master分支在我们最初转换为GitFlow时从develop分支分支形成的副作用，而不是我们使用GitFlow Releases功能。

有没有人对这种设置或症状有任何经验，或者有任何建议来尝试解决它？我们考虑尝试通过使用GitFlow Release功能或使用Git属性来忽略合并文件来重新创建master，但感觉可能有更明智的方法来解决这个问题。

- Matt Eland

---

你找到解决这个问题的方法了吗？ - Joze

抱歉回复晚了，但实际上并没有。答案是所有内容都会在合并时流入分支，因此您需要确保不想保留的更改已经在上游。在发布分支上进行所需更改可能有所帮助，然后再将其移动为新的主分支，但我不确定。 - Matt Eland

Answer 1

这是由于自"合并基础"（大致上是指master和develop的历史记录中最近的提交）以来，你在master上的配置发生了改变。我觉得这意味着你的同事是正确的。严格来说，使用特定的GitFlow工具并不重要，但是develop应该从master分支出去（而不是反过来），更重要的是更改不应直接应用于master。

如果这些陈述对你来说看起来不合理，那么你所拥有的不是像你所说的GitFlow的“标准设置”。

在GitFlow设置中，依赖版本与任何代码更改并没有太大的区别。通常只会发生以下几件事情：

最常见的事情应该是，一个功能需要一个依赖项（或依赖项的新版本），因此该更改进入了功能分支的构建配置中。然后它最终合并到develop中，然后在发布分支上进行携带，最终合并到master中。

另一个可能性是，在热修复中更改版本号，因为你需要一个依赖项的安全补丁或其他东西。当然，这应该合并到master和develop。

最后，您可以更改发布分支上的依赖项；但是同样地，这些更改预计将合并到master和develop。

共同点是，所有这些都应该向一个共同的配置发散。这不是偶然的；如果你声称想要版本在prod上保持不同，那么你就是在说你不希望开发人员能够进行准确有效的测试。

如果你遵循GitFlow，那么develop分支和master分支之间依赖项的版本差异唯一的原因就是更改尚未流向master；在这种情况下，热修复合并不会认为master版本应该覆盖develop版本，因为合并基础将在master版本上。

当然，还有一些配置元素应该在生产和开发环境之间保持坚持不变（例如连接字符串）。我建议解决此问题时考虑在构建过程中而不是源代码控制工作流中进行。

- Mark Adelsberger

Answer 2

简单来说，gitflow 隐式地将整个 master 合并到 develop 中，当您像这样合并时，存在一些问题，即如何使 master 的某些更改远离 develop。（至于您的“我的同事断言...”我没有完全理解它，但无论分支最初是如何无关的，合并仍旧会使它们相同，正如另一个答案所解释的那样）

我唯一能建议的是，在合并后撤销 develop 中的该配置。下一次在 master 中进行更改时，它将触发合并冲突，您可以手动以所需的方式解决它。

- max630