如何处理 git 存储库中广泛的代码格式更改
我们有一个包含大约 500,000 行代码的项目，使用 git 进行管理，其中大部分已经有好几年了。我们将进行一系列修改，以使旧代码在命名约定、异常处理、缩进等方面符合开发人员社区的当前标准和最佳实践。
您可以将其视为介于漂亮打印和低级/机械重构之间的东西。
此过程可能会触及代码库中的几乎每一行代码（~85%），并且某些行将进行多达五次修改。所有更改都旨在保持语义中立。
We have a project with around 500,000 lines of code, managed with git, much of it several years old. We're about to make a series of modifications to bring the older code into conformance with the developer community's current standards and best practices, with regards to naming conventions, exception handling, indentation, and so forth.
You can think of it as something between pretty printing and low level/mechanical refactoring.
This process is likely to touch almost every line of code in the code base (~85%), and some lines will be subject to as many as five modifications. All of the changes are intended to be semantically neutral.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不知道如何最好地处理您所描述的一些更具侵入性的更改，但是...
使用这些选项来进行过滤：
-w选项使git忽略空格的变化，这样你就可以更容易地看到真正的差异。-M和-C选项使其遵循重命名和复制；在 git Blame 的情况下，还会跨文件移动和复制代码片段。请参阅： explainshell.com -
git diff -w -M - CI don't know how best to deal with some of the more invasive changes you're describing, but...
Use these options to
git blameandgit diffto filter:-woption causes git to ignore changes in whitespace, so you can more easily see the real differences.-Mand-Coptions make it follow renames and copies; in the case of git blame also moving and copying of fragments of code across files.See: explainshell.com -
git diff -w -M -C我建议在一个中央 Git 存储库中一次一步地进行这些演变（中央如“所有其他存储库要遵循的公共参考”）：
但不是“缩进-重新排序-重命名” -...-一个巨大的提交”。
这样，您就可以给 Git 一个合理的机会来跟踪重构修改中的更改。
另外，我不会接受任何未应用相同内容的新合并（从其他存储库中提取）在推送代码之前进行重构。
如果应用格式过程对获取的代码带来任何更改，您可以拒绝它并要求远程存储库首先符合新标准（至少在进行更多推送之前从存储库中提取）。
I would recommend making those evolutions one step at a time, in a central Git repo (central as in "public reference for all other repositories to follow):
But not "indentation-reordering-renaming-...-one giant commit".
That way, you give to Git a reasonable chance to follow the changes across refactoring modifications.
Plus, I would not accept any new merge (pulled from other repo) which do not have applied the same refactoring before pushing their code.
If applying the format process brings any changes to the fetched code, you could reject it and ask for the remote repo to conform to the new standards first (at least by pulling from your repo before making any more push).
您还需要一个允许主动忽略空白的合并工具。 p4merge 就是这样做的，并且可以免费下载。
You will also need a mergetool that allows agressive ignoring of whitespace. p4merge does this, and is freely downloadable.
这个问题有一个很好的解决方案。简单使用一下
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可能会有所帮助，但我不确定。This question has a good solution for it. Briefly use
git filter-branch.I used for myself this code:
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" HEADWhich
./emacs-scriptis a script I wrote using emacs to change the code-style, it simply just callindent-regionon each file.This code works fine if there is not any file that deleted or removed from repository, On that situation using
--ignore-unmatchmay be helpful but I'm not sure.