gpt4 book ai didi

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

转载 作者:太空狗 更新时间:2023-10-29 13:52:57 24 4
gpt4 key购买 nike

我的 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 更改为 squashfixup 。它们之间的唯一区别是您是否有机会为新的组合提交编辑提交消息:
  • 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/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com