解决 git auto merge from release branch to master 冲突

Question

我什至不知道如何总结这个问题，所以很难搜索类似的问题。

我的公司有我们的 repos 设置，因此我们的下一个版本的工作是通过从 master 分支创建一个分支，进行更改，然后将该分支合并回 master 来完成的。当我们进行发布时，我们会从 master 创建一个“release-”分支。现在，如果该版本中的某些内容需要修改，我们从 release- 分支创建一个分支，进行更改，然后合并回发布分支。

我应该注意的是，不允许任何人直接向 master 或 release 分支提交任何内容。更新这些分支的唯一方法是在另一个分支中工作，从该分支创建一个拉取请求到主分支或发布分支，获得该 PR 批准，然后合并它。

然后，我们从发布分支“自动合并”到 master，以确保 master 始终也能获得这些更改。我不确定这是否是一个好主意（它肯定经常让我头疼），也没有兴趣讨论这个问题，但我需要弄清楚如何解决以下情况。

我有一个文件，somecode.java。我们从 master 分支了 release-2，做了发布。我继续为下一个版本工作，并在 master 分支中更新了 somecode.java。
现在我们发现发布 2 存在问题，我不得不从发布 2 分支创建一个“修复”分支。在 fixit 分支中，我更新了 somecode.java，然后将其合并回 release-2 分支。
现在从 release-2 到 master 的自动合并失败，因为 release-2 中 somecode.java 的版本与 master 中的版本冲突。
有什么方法可以告诉 Git
(1) 将版本保留在 master 中（首选，因为 release 2 中的更改已被之前所做的更改所取代，但在创建 release-2 分支之后，在 master 中）或
(2) 用 release-2 中的较新版本覆盖 master 中的版本（然后我将稍后更新 master 版本，并在那里对其进行更改）？

我知道我可以拒绝从 release-2 到 master 的自动合并拉取请求，但是任何时候其他人尝试更新 release-2 分支时，当他们的自动合并为尝试过。

我试着做一个
git checkout origin/master -- somecode.java
在我的“fixit”分支中工作时，然后将文件更新为我们在第 2 版修复中需要它的方式。
我认为这相当于告诉 Git“对于这个文件，我们从 master 版本开始，所以当我们在这里更新它时，它应该清楚地覆盖 master 中的版本”。基本上是上面的选项（2）。
但这没有任何区别，并且在从 release-2 合并到 master 时仍然存在相同的冲突。

有什么建议吗？

Answer 1

用 release-2 中的较新版本覆盖 master 中的版本

这就是我建议的策略。我对自动合并一无所知——它多久回来一次并尝试再次执行此操作？但是，如果您在 master 上工作并检查发布分支的 somecode.java，覆盖 master 的版本，并将其添加-提交-推送到服务器，则自动合并随后可以成功。然后您可以再次编辑 somecode.java 以使其正确（可能是通过您在结帐前保留在其他地方的副本）。

但正如您所说的那样，整个自动合并策略都是值得怀疑的。它以一种对我来说毫无意义的方式搅浑水。我想知道，尝试将纯粹用于已发布版本的修补程序读回 master 有什么好处？如果修补程序中的某些东西被证明是有用的，可以手工挑选它来掌握；否则，它应该保留在单独的发布分支上，因为这些显然是单独的历史和单独的开发线。