我的 git push
很慢所以我调查并发现文件夹.git/objects
占用~450MB。
完整的项目只有约 6MB,但我添加了 140MB 大的文件。由于github不允许文件那么大,我已经删除了它们,然后git add -A
并尝试再次提交,但需要很长时间并且似乎上传了很多。
它需要永远在:
writing objects: 97% (35/36), 210.17 MiB | 49.00 KiB/s
如何修复我的 git 存储库?
最佳答案
提交是“永远的”
请记住,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
,或者进行多次额外提交)。
关于git - .git 中的 Objects 文件夹对于我的小项目来说非常大,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/38415649/