Git存储库的大小比它应该大 [英] Git repository size is larger than it should be

查看:80
本文介绍了Git存储库的大小比它应该大的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我在个人服务器上使用git,并且我有一个旧的repo,我需要更新。我删除了一堆旧文件并提交并推送了更改。我在我的服务器上使用了一个Web UI( Gitlist )。当我使用此GUI将repo作为zip文件下载时,它的大小正确,大小约为41MB。然而,当我克隆repo时,由于其中一个 ./git/objects/packet 文件的大小大约为900MB,所以它出现在更接近gig的地方。



为什么repo这么大,当它真的要小得多?

解决方案

推送删除文件的提交不会使git repo变小。



您需要在git repo的历史记录中删除这些文件,以便它的大小会缩小。

这通常与 git filter-branch git gc --aggressive --prune = now :请参阅减少git存储库大小

(别忘了: 单独git gc 实际上可以增加th的大小)



要删除大文件,

总之,不要混淆:




  • 一个zip图片(代表回购协议的一个版本)

  • 完整的回购(代表所有提交)



您作为zip下载的HEAD确实更小(您删除了文件)。

但完整的历史记录仍然引用它们。


So I'm using git on a personal server and I had an old repo that I needed to update. I removed a bunch of old files and committed and pushed the change. I'm using a web UI for it on my server (Gitlist). When I use this GUI to download the repo as a zip file, it comes out to the correct size, about 41MB. However, when I clone the repo, it comes out to something closer to a gig due to the size of one of the ./git/objects/pack files is about 900MB.

Why is the repo so large when it really should be much smaller?

解决方案

Pushing a commit which removes files doesn't lake the git repo smaller.

You need to remove those files across the history of the git repo in order for it size to shrink.
This is typically done with a combination of git filter-branch and git gc --aggressive --prune=now: see "Reduce git repository size".
(Don't forget: a git gc alone can actually increase the size of the repo!)

To remove large files, the tool BFG can help too.

In short, don't mix-up:

  • a zip image (representing one revision of a repo)
  • the full repo (representing all commits)

The HEAD that you download as a zip is indeed smaller (you removed files).
But the full history still references them.

这篇关于Git存储库的大小比它应该大的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆