我们有一个相当大的代码库，包含大约 60000 个提交。我们想在保留 git 历史记录的同时重新格式化所有 .java 文件。因此，我们采取的方法是使用 git filter-branch --tree-filter 重新格式化整个代码库，同时保持历史完整。但是，有几个问题我找不到答案。
当我应用 --tree-filter 并传递重新格式化根目录中所有 .java 文件的命令时，重写发生了，但在最后，我看到了所有 .java 文件暂存区。重写的每一步都需要提交还是自动发生？
git filter-branch 似乎接受一系列提交，所以这让我想知道是否可以在每次重写和恢复之前保存提交 ID，以防失败。恢复很重要，因为整个过程可能需要几天时间才能完成(即使在强大的计算实例上也是如此)。
为了重新格式化整个代码库，--index-filter 会起作用吗？
更新:澄清
- 代码库大约有 220 万行 Java 代码。不进行 git 重写将导致大约 10%-12% 的代码库归于错误的作者。那是大约 200,000 行 java 代码，这是我们想要避免的。 Git 重写使做出更改的人看起来像是以正确的方式进行了更改。
最佳答案
作为 the BFG 的作者(比 git-filter-branch 更快、更简单的替代方案)，我倾向于提及它，尽管它没有开箱即用地重新格式化 Java 源代码。
您提到 git-filter-branch 操作的失败后恢复会很有帮助——当然，这是因为 git-filter-branch 太慢了。有 no way to resume a git-filter-branch操作 - 但如果速度更快，那就不是什么大问题了。 BFG 可以是 many hundred times faster与 git-filter-branch 不同，因为它只清除任何给定版本的文件一次 - 与 git-filter-branch 不同，它每次提交都会清除相同的文件。
BFG 支持文件中的直接文本替换，但正如我所说，它不进行 Java 源代码重新格式化。有两种方法可以让它发挥作用:
- 调用 BFG 作为库，作为 Christian Hoffmeister recently did - 在你的情况下，传递自定义 TreeBlobModifier调用 Jalopy或其他一些 Java 源代码格式化程序。
- 更改 BFG，使其支持 shelling out 调用任意 bash 命令 - 有点像
git-filter-branch的--tree-filter或--index-filter- 但我仍然希望更快。
选项 2 实现起来并不难。不过，请问您能否详细说明一下为什么要采取这种大刀阔斧的行动——改写历史？相对于重写提交和让每个人适应改变的历史的麻烦，拥有一个完美格式化的历史真的有实质性的好处吗？为什么不一次性重新格式化您的最新提交？
关于git - 使用 git rewrite 重新格式化整个代码库，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26105526/