在 github 拉取请求上反复获得非常大的差异

Question

我正在开发一个使用 GitHub 来管理我们的工作流程的项目。我们已经有了

main

，并且为每个版本剪切了一个新的

release/24XX.XX

分支。当版本发布后，我们将其合并回

main

并剪切一个新的

release/XXXX.XX

分支。

开发是在功能分支上完成的，当它们准备好时，它们会被压缩到当前开放的发布分支中。如果有人在新的发布分支被剪切时打开了一个发布分支，他们会将其合并到他们的分支中，并将其 PR 到该新的发布分支中。

存储库中出现了问题，有时当我们提出 PR 时，它会显示 500 多个已更改的文件。如果您的分支需要从新版本进行更新，当您的 PR 仅更改了 3 个文件时，您可能会面临 30 多个冲突。解决这些冲突并推动合并将导致 PR 上的正确差异，但这显然不是最佳的，并且很可能会出错。过去两个版本中一直存在这种情况，我们认为一旦上一个版本合并回

main

，问题就会得到解决，但事实并非如此。

我们如何诊断问题？

Answer 1

我假设您正在使用 Gitflows（即开发是开发分支，

main

是发布） 你的主分支有保护规则吗？如果否，则可能有人在 main 中进行了 rebase 并强制推送，这改变了提交的哈希值，但内容是相同的。 要调试它，发布后您的

develop

和

main

应该相同。创建从

develop

到

main

和

main

到

develop

的 PR，它应该具有零差异和零变化。如果不存在，那么问题是您的

main

和

develop

由于变基和强制推送而出现分歧。 解决方案：您需要将

main

合并到

develop

。