【Git】Gitee大文件提交失败？三步高效清理历史记录

1. 问题定位：你的Gitee仓库为什么“卡住”了？

你有没有遇到过这种情况？在本地开发得好好的，代码也写完了，准备推送到Gitee仓库，结果一个 git push 命令下去，终端就卡在那里，半天没反应，最后弹出一个让你血压升高的错误提示：“remote: error: File: xxxxxx is 150.00 MB; this exceeds GitHub‘s file size limit of 100.00 MB”。虽然提示里写的是GitHub，但Gitee对单个文件的大小限制同样严格，通常也是100MB左右。这时候你可能会想：“我明明已经把那个大文件删除了，重新commit了，怎么还是推不上去？” 这就是我们今天要解决的核心痛点：你删除的只是工作区的文件，Git的历史记录里，还完整地保存着那个大文件的每一次提交版本。

这就像你写了一本日记，其中一页不小心用墨水涂了一大片。你后来把这页纸撕了，换了一张新纸重写。但是，你之前涂鸦的那一页，依然被装订在你日记本的历史页码里。Git就是这样一个严谨（或者说“固执”）的版本控制系统，它的设计哲学是记录每一次变更，而不是抹去历史。所以，仅仅 rm 文件然后 commit，只是在最新的“快照”里标记这个文件删除了，而仓库的 .git 文件夹里，那个大文件的数据对象依然存在，导致整个仓库体积臃肿，无法推送到有大小限制的远程仓库（如Gitee）。

我刚开始用Git的时候也踩过这个坑。当时项目里不小心混入了一个几百兆的测试数据压缩包，commit了好几次。后来发现Gitee推不上去，我就天真地删了文件，提交删除操作，结果push时依然报错。折腾了半天才明白，问题出在“历史记录”上。所以，第一步不是盲目操作，而是要像侦探一样，准确地找出是哪些“大家伙”藏在你的仓库历史里，拖了后腿。

2. 第一步：精准“扫描”，揪出历史中的大文件

在动手清理之前，我们必须先知道敌人在哪里。盲目操作可能会误伤其他文件。Git本身提供了一些强大的命令来审视仓库的内部数据。这里我分享一个我用了很多年的命令组合，它能帮你快速找出仓库历史中体积排名前十的“大块头”。

打开你的终端（命令行），进入你的项目根目录，然后输入下面这条看起来有点长的命令：

git rev-list --objects --all | grep -E `git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}' | sed ':a;N;$!ba;s/\n/|/g'`

别被它的长度吓到，我们拆开看看它每一步在做什么，理解了原理，用起来才放心。

1. git verify-pack -v .git/objects/pack/*.idx：这个命令是核心侦察兵。Git为了节省空间，会把很多对象打包（pack）成 .idx 和 .pack 文件。verify-pack 命令就是用来查看这些打包文件里具体内容的，-v 参数表示输出详细信息。
2. sort -k 3 -n：上一步命令会输出很多行信息，其中第三列（-k 3）就