GitFlow 正在将 master 的不需要的方面 merge 到修复完成的开发中

Question

我们使用具有相当标准设置的 GitFlow:

• 代表最新作品的Master
• 发展代表持续发展
• hotfixes/x 下的一些修补程序代表正在进行的错误修复
• features/x 下的一些功能代表下一版本的正在开发中的更大功能。

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

我们发现，当我们进行 GitFlow 修补程序并完成该修补程序时，在它从修补程序分支 merge 到开发时，它会尝试将这些配置差异从 master merge 到开发中，即使这些配置更改不是作为修补程序的一部分完成的。

我的同事断言，当我们最初迁移到 GitFlow 而不是使用 GitFlow Releases 功能时，这个问题很可能是主分支通过从 develop 分支形成的副作用。

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

Answer 1

这是由于 master 和 develop 之间的“merge 基础”后，您在 master 上的配置在某处发生了更改。 (粗略地说，“merge 基础”是 master 和 develop 历史上最近的提交。)我想说这意味着你的同事在正确的轨道上。您是否使用特定的 GitFlow 工具并不严格，但是 develop 应该从 master 分支出来(而不是相反)，并且(也许更重要)不应将更改直接应用于 master。

如果您觉得这些陈述不合理，那么您所拥有的并不是 GitFlow 的“相当标准的设置”。

在 GitFlow 设置中，依赖版本与任何代码更改都没有什么不同。通常只有几件事会发生:

最常见的事情应该是，一个功能需要一个依赖项(或新版本的依赖项)，以便更改进入功能分支上的构建配置。从那里它最终 merge 到 develop，然后在 merge 到 master 的发布分支上进行。

另一种可能性是版本号在修补程序中被更改，因为您需要安全补丁或依赖项。当然，这应该 merge 到 master 和 develop 中。

最后，您可以更改发布分支上的依赖项；但同样，这些更改预计会 merge 到 master 和 develop 中。

共同的主题是，这些通常都应该汇聚到一个共同的配置。这不是错误的；如果您声称希望版本在生产中保持不同，那么您就是在说您不希望您的开发人员能够进行准确有效的测试。

如果您遵循 gitflow，那么 develop 与 master 具有不同版本的依赖项的唯一原因是更改尚未流向 主人;在那种情况下，修补程序 merge 不会认为 master 版本应该覆盖 develop 版本，因为 merge 基础将在 master 上> 版本。

当然，有配置元素在生产环境和开发环境之间应该始终不同(例如连接字符串)。我的建议是在构建过程中解决此问题，而不是在源代码控制工作流程中解决。