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

Question

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

您可以将其视为介于漂亮打印和低级/机械重构之间的东西。

此过程可能会触及代码库中的几乎每一行代码（~85%），并且某些行将进行多达五次修改。所有更改都旨在在语义上保持中立。

是否有任何方法可以使更改对 gitblame 等透明，以便一个月后查看代码时，我们将看到引入逻辑的提交，而不是缩进或大写的提交改变了？

从未经过此过程的分叉中提取合并的最佳方法是什么？我目前的计划是让一个脚本克隆分叉的存储库，对其及其基础应用自动化流程，比较它们，然后应用差异。但我很想得到一个更清晰的答案。

是否还有其他我没有看到的此类问题？如果有，可以采取哪些措施来缓解这些问题？我认为 git bisect 等应该没问题，git log 等。除非你小心，否则跨越鸿沟会很烦人，并且 git diff 将无望，但我不相信我没有忽略另一个痛点。

Answer 1

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

使用这些选项

git blame

和

git diff

进行过滤：

• -w

  选项使git忽略空白的变化，这样你就可以更容易地看到真正的差异。

• -M

  和

  -C

  选项使其跟随重命名和副本；在 git Blame 的情况下，还会跨文件移动和复制代码片段。

参见：explainshell.com -

git diff -w -M -C

Answer 2

我建议在中央 Git 存储库中一次一步地进行这些演变（中央存储库如“供所有其他存储库遵循的公共参考”）：

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

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

这样，您就可以给 Git 一个合理的机会来跟踪重构修改中的变化。

另外，我不会接受任何新的合并（从其他存储库中提取），这些合并在推送代码之前没有应用相同的重构。
如果应用格式过程会给获取的代码带来任何更改，您可以拒绝它并要求远程存储库首先符合新标准（至少在进行更多推送之前从您的存储库中拉取）。

Answer 3

您还需要一个允许主动忽略空格的合并工具。 p4merge 就是这样做的，并且可以免费下载。

Answer 4

这个问题有一个很好的解决方案。短暂使用

git filter-branch

。

我自己使用了这个代码：

git filter-branch --tree-filter "git diff-tree --name-only --diff-filter=AM -r --no-commit-id \$GIT_COMMIT | grep '.*cpp\|.*h' | xargs ./emacs-script" HEAD

其中

./emacs-script

是我使用emacs编写的用于更改代码风格的脚本，它只是在每个文件上调用

indent-region

。

如果没有从存储库中删除或删除任何文件，则此代码可以正常工作，在这种情况下使用

--ignore-unmatch

可能会有所帮助，但我不确定。