如何在git存储库中处理广泛的代码格式更改

Question

我们有一个包含大约500,000行代码的项目,使用git进行管理,其中大部分已经使用了几年.我们即将进行一系列修改,以使旧代码符合开发人员社区的当前标准和最佳实践,包括命名约定,异常处理,缩进等.

你可以把它想象成漂亮的印刷和低级/机械重构之间的东西.

这个过程很可能触及代码库中的几乎所有代码行(~85%),并且一些行将受到多达五次修改.所有更改都旨在在语义上保持中立.

是否有任何方法可以使更改对git blame等透明,这样当从一个月后查看代码时,我们会看到引入逻辑的提交,而不是更改缩进或大小写的提交？

从没有经历过这个过程的叉子中拉出合并的最佳方法是什么？我现在的计划是让一个脚本克隆分叉的repo,将自动化过程应用于它及其基础,对它们进行区分,然后应用diff.但我希望得到更清晰的答案.

还有其他我没有看到的问题,如果有的话可以做些什么来减轻它们？我认为git bisect等应该没问题,git log等等.除非你小心谨慎,否则git diff会很烦人,但是我不相信我不会忽视另一个痛点.

Answer 1

我不知道如何最好地处理你所描述的一些更具侵略性的变化,但......

该-w选项git blame,git diff以及其他导致混帐忽略空白的变化,所以你可以更容易地看到真正的差异.

Answer 2

我建议一次一步地进行这些改进,在一个中央的Git仓库(中央,如"所有其他仓库的公共参考"):

• 缩进
• 然后重新排序方法
• 然后重命名
• 然后 ...

但不是"缩进 - 重新排序 - 重命名-...-一个巨大的提交".

这样,你就给Git一个合理的机会来跟踪重构修改后的变化.

另外,我不接受在推送代码之前没有应用相同重构的任何新合并(从其他仓库中提取).
如果应用格式化过程会对获取的代码进行任何更改,您可以拒绝它并要求远程仓库首先符合新标准(至少在进行任何更多推送之前从您的仓库中提取).

Answer 3

您还需要一个允许大量忽略空格的合并工具.p4merge这样做,可以免费下载.