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

Question

我在一个非常大的项目上工作，我们最终决定实施一个通用的格式化程序，以帮助我们避免合并冲突，并在查看PR时有更好，更清晰的差异（请不要对此进行评论 - 它是不可协商的这点）。在整个代码库中运行格式化程序并在一个提交/ PR中获取所有格式化似乎真的很好。问题是我们同时有多个正在进行的版本。像这样：

___master_____________________ \ \__release_1_________________ \ \ \__release_2_______\________

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

1. 冻结回购中的所有更改。从版本1合并到版本2，因此版本2是最新的，版本1更改为日期。
2. 在版本1中进行格式更改。这可能会触及repo中的大多数行。提交和公关更改。
3. 合并从版本1到版本2的更改。如果有任何冲突，请选择文件的版本2版本。
4. 对版本2中仍未格式化的任何文件进行格式更改（可能只是新文件或步骤3中存在合并冲突的文件）。提交和公关更改。

问题是 - 这是否可行并最小化我们的合并冲突，我们定期合并从版本1到版本2？这会导致Git失去共同的祖先信息，从而导致更多问题向前发展吗？

我们的第二个选择是放弃版本1并重新格式化版本2中的所有内容，但我们假设这会对版本1的任何更改和未来版本2中的任何更改造成一些讨厌的合并冲突。

Answer 1

我可能会通过使用git filter-branch重写历史来实现这一目标，这将是简单且无冲突的。但显然你必须得到你所有的开发者去接受重写的历史，如果他们有当地的分支，藏匿等等，这将是一场噩梦。

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

这假设代码更改完全自动化，当然。并且... SE损坏了您的ASCII艺术，因此需要注意。