git - .git 中的 Objects 文件夹对于我的小项目来说非常大

Question

我的 git push很慢所以我调查并发现文件夹.git/objects占用~450MB。

完整的项目只有约 6MB，但我添加了 140MB 大的文件。由于github不允许文件那么大，我已经删除了它们，然后git add -A并尝试再次提交，但需要很长时间并且似乎上传了很多。

它需要永远在:

writing objects:  97% (35/36), 210.17 MiB | 49.00 KiB/s 

如何修复我的 git 存储库？

Answer 1

提交是“永远的”

请记住，Git 会“永远”保存每个提交(不用担心，这是用引号引起来的!)。

这意味着当你添加存档并提交时，你把它放进去，然后当你删除存档并提交时，你又添加了一个额外的提交，上面写着“既然你已经永远保存了这个巨大的存档，把它从工作版本，因为我们不需要它”......但它仍然在永久审计跟踪中，“每次提交永远”记录。所以它在您的存储库中，您将“必须”推送它。再次注意“必须”周围的引号。

永远只在您(以及拥有副本的其他所有人)希望它成为时

请参阅 How to remove/delete a large file from commit history in Git repository? 你的问题基本上是重复的，但在你去那里的答案之前，请注意你还没有成功推送这些提交，因为 GitHub 默认说“不，那真的很大”。这意味着您可以自由地使用重写操作:还没有其他人拥有您提交的副本。

对于这种情况，我通常认为 git rebase -i 是最简单的清理方法。特别是，假设您的 git rebase -i 编辑配方中有以下提交序列:

pick a123456 add feature foo
pick b123456 rm giant file accidentally added in a123456
pick ...

在这种特殊情况下，错误(“添加巨型文件”)和修复(“删除巨型文件”)彼此相邻。假设您可以告诉 Git:“只需将两次提交 merge 为一次提交，如果您先进行第一次提交，然后再进行第二次提交，就会发生这种情况。”也就是说，让我们做所有事情，包括添加巨型文件，但是在提交之前，让我们也做 remove-giant-file，然后才提交。

嗯，“squash”和“fixup”是两个告诉 Git 确切信息的命令。只需将 pick 更改为 squash 或 fixup 。它们之间的唯一区别是您是否有机会为新的组合提交编辑提交消息:

squash :进行组合提交，并在日志消息上调出编辑器，其中最初包含两个原始日志消息。

fixup :进行组合提交，但使用来自非修复提交的日志消息，完全丢弃修复的消息。

所有历史编辑操作复制提交

正如我们在顶部指出的，提交是永远的。他们不能改变。 rebase 的作用(以及链接问题的答案中提到的“BFG”)是将错误提交复制到新的、略有不同的、更好的(我们希望)提交。然后在复制完成后，我们让 Git 将错误的提交放在一边，并使分支名称指向新的副本:

A--B--C--D--E   <-- master

糟糕，提交 C 很糟糕，我们制作了 D 来删除大文件，然后我们也进行了无关的修复 E。所以现在我们将提交 C -through- E(我们必须复制 E 因为我们必须从坏点向前复制所有内容)到更新、更好的提交:

     C--D--E   [abandoned]
    /
A--B--C'--E'   <-- master

我们将原来的 C-D-E 链推开，并使用我们的新 C'( C 被压扁或修复到其中的 D 副本)和 E'( E 的副本)并使分支名称，在这种情况下， master 指向 E' 而不是 E 。现在我们可以 push ，或者强制 push 。

如果我们已经成功推送，我们就必须强制推送。如果我们必须强制推送，这意味着其他人可能已经捕获了我们糟糕的 C-D-E 链并且可能正在使用它，他们也必须恢复。如果他们做错了，他们甚至可能会把 C-D-E 带回来! (通常通过 merge 。)

但是如果没有其他人拥有 C-D-E ，我们可以放弃它们并且知道它们永远不会回来(除非我们去寻找它们)。所以现在我们可以自由地(非强制)推送更正后的 C'-E' 链。

如果您的修复不是很好

如果修复错误提交的提交紧跟在错误提交之后，则上述内容很棒:

pick a123456 add feature foo
pick b123456 rm giant file accidentally added in a123456
pick ...

但也许“rm 巨型文件”提交不会在错误提交之后立即出现，或者可能混入了其他东西。错误，这很简单，只需按照 rebase -i 说明进行操作即可。你可以做两个 rebase:一个是重新排序，一个是压缩/修复；或者，如果您愿意，可以一次性尝试重新排序和压缩/修复。

如果没有......好吧，这就是您可能想要使用 filter-branch 或另一个(链接)问题中提到的 BFG 的时候:这些可以对提交进行复杂的手术。交互式 rebase 只自己做一些简单的事情，而将复杂的方法留给您(例如，您可以在交互式 rebase 中间使用 git commit --amend，或者进行多次额外提交)。