.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会"永远"保存每次提交(不用担心,这是引用的原因!).

这意味着当您添加存档并提交时,您将其放入,然后当您删除存档并提交时,您会进行另一个提交,即"现在您已经永久保存了这个巨大的存档,将其取出该工作版本,因为我们不需要它" ......但它仍然在永久的审计线索中,'每一个承诺永远’的纪录.所以它在你的存储库中,你将"必须"推动它.再次,请注意"必须"的引号.

永远只有你(以及其他人都有副本)想要它

请参阅如何从Git存储库中的提交历史记录中删除/删除大文件？ 你的问题基本上是重复的,但在你去那里的答案之前,请注意你还没有成功推送这些提交,因为GitHub默认说"不,这真的很大." 这意味着您可以自由地使用重写操作:没有其他人拥有您的提交副本.

对于像这样的情况,我通常认为git rebase -i是最简单的清理方法.特别是,假设您在git rebase -i编辑配方中有这样的提交序列:

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

在这种特殊情况下,错误("添加巨型文件")和修复("删除巨型文件")彼此相邻.假设您可以告诉Git:"只需将两个提交合并到一个提交中,即可完成第一次提交然后第二次提交时会发生的情况." 也就是说,让我们做的一切,包括加入巨人文件,但随后提交之前,我们也做了删除巨型文件,只有然后提交.

好吧,"squash"和"fixup"是告诉Git的两个命令.只需更改pick为squash或fixup.它们之间的唯一区别是您是否有机会编辑新组合提交的提交消息:

• squash:进行组合提交,并在日志消息上调出编辑器,该消息最初包含两个原始日志消息.
• fixup:进行组合提交,但使用来自非fixup提交的日志消息,完全丢弃fixup的消息.

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

正如我们在顶部提到的那样,提交是永远的.它们无法改变.rebase的作用(以及链接问题的答案中提到的"BFG")是将不良提交复制到新的,略有不同,更好 - (我们希望),提交.然后在完成复制之后,我们让Git将不良提交放在一边,并使branch-name指向新副本:

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

哎呀,提交C很糟糕,我们D删除了大文件,然后我们也做了不相关的修复E.所以现在我们复制提交 - C通过 - E(我们必须复制,E因为我们必须将所有内容从坏点向前复制)到更新,更好的提交:

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

我们将原来的C-D-E链条推开,并使用我们新的C'(C已经D压缩或修复它的E'副本)和(副本E)并使分支名称,master在这种情况下,指向E'而不是E.现在我们可以推动,或者强迫推动.

如果我们已成功推动,我们必须强制推动.如果我们必须强制推动,那意味着其他人可能已经抓住我们的坏C-D-E链并且可能正在使用它,他们也必须恢复.如果他们做错了,他们甚至可能会带C-D-E回来!(通常通过合并.)

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

如果您的修复程序不是很好

如果您修复错误提交的提交恰好在错误的提交之后,则上述情况非常好:

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

但也许"rm巨型文件"提交不是在错误提交之后,或者它可能有其他东西混合在一起.如果你可以简单地重新命令提交,以便一个单独的"rm巨型文件"提交确实在错误,这很容易,只需按照rebase -i说明操作即可.你可以做两个rebase:一个重新排序,一个压缩/修复; 或者如果你愿意,你可以一次性尝试重新排序和压缩/修复.

如果不是......好吧,这就是你想要去的地方filter-branch或者另一个(链接)问题中提到的BFG:这些可以在提交时进行复杂的手术.交互式rebase只能单独执行简单的操作,并为您留下复杂的方法(例如,您可以git commit --amend在交互式rebase的中间使用,或者执行多个其他提交).