Git 中大规模更改避免合并冲突到下游分支的策略

Question

我在一个非常大的项目上工作，我们最终决定实施一个通用格式化程序来帮助我们避免合并冲突，并在查看 PR 时获得更好、更清晰的差异（请不要在这方面使用 cmets - 这是不可协商的这点）。似乎只在整个代码库上运行格式化程序并在一次提交/PR 中排除所有格式化会非常好。问题是我们同时有多个版本在进行中。像这样的：

___master_____________________ \ \__release_1_________________ \ \ \__release_2_______\________

请注意从第 1 版到第 2 版的合并。这些合并每周发生一次，并且是需要手动解决的合并冲突的常见来源。如果我们最终格式化所有版本 1 分支，然后尝试将这些更改合并到版本 2，我们假设会有大量的合并冲突。我们已经考虑过解决此问题的一种策略如下：

1. 冻结存储库中的所有更改。从第 1 版合并到第 2 版，以便第 2 版与第 1 版的更改保持同步。
2. 在版本 1 中进行格式更改。这可能会触及 repo 中的大多数行。提交和 PR 更改。
3. 合并从版本 1 到版本 2 的更改。如果有任何冲突，请选择文件的版本 2 版本。
4. 对版本 2 中未格式化的任何文件进行格式更改（可能只是新文件或在步骤 3 中存在合并冲突的文件）。提交和 PR 更改。

问题是 - 在我们从版本 1 到版本 2 的定期合并中，这是否可行并最大限度地减少我们的合并冲突？这会导致 Git 丢失共同的祖先信息，从而导致更多的问题吗？

我们的第二个选择是放弃第 1 版并重新格式化第 2 版中的所有内容，但我们认为这将导致对第 1 版所做的任何更改以及未来合并到第 2 版中的一些令人讨厌的合并冲突。

Answer 1

我可能会通过使用git filter-branch 重写历史来做到这一点，这将是简单且无冲突的。但很明显，你必须让所有的开发人员重新获得重写的历史，如果他们有当地的分支机构、藏匿处等，那将是一场噩梦。

因此，如果您希望坚持自己的方法，那么我建议您在发布时进行单独的格式化提交。然后，3 路合并应该能够轻松地在版本之间进行进一步的合并。为了避免进一步的极端冲突和倒退，您应该在合并之前对所有未来的 PR 分支进行自己的重新格式化。

当然，这假设代码更改是完全自动化的。而且... SE 破坏了您的 ASCII 艺术，所以请谨慎购买。