前言
哈喽!好久不见~
最近在思考转型的事情,好久没有更新文章了
不过看到我之前开发的视频剪辑工具 Clipify 收获了不少 star ,让我想起之前画的饼似乎才实现了一点点,所以利用了周末的空闲时间给 Clipify 项目重构了一下界面以及开发一些新功能。
中途意识到现在使用的 WinForms + Blazor 技术栈,就像马拉火车,有种蒸汽朋克的复古感,虽然使用前端技术开发的界面很好看,但 WinForms 不能跨平台终究不是长久之计。
于是我便着手尝试迁移到 MAUI,虽然还不能支持 Linux,至少 Mac 还是可以的,也算是跨平台了吧...
然而我还没把项目跑起来呢,一不小心把一堆静态资源给提交进去了
就是下面这些文件
Clipify.Maui/wwwroot/lib/
Clipify.Maui/wwwroot/css/*.min.css
Clipify.Maui/wwwroot/temp/
这下 git push
超级慢,而且会占用大量空间
还好最终在大模型爷爷的帮助下解决了这个问题
不过我想总不能老是去打扰大模型爷爷啊,问题解决了还是得记录一下,以后遇到类似的情况也好处理。
使用git原生命令
这个问题其实老生常谈了
网上能查到的很多文章都会告诉你可以用以下命令解决
bash
git rm -r --cached Clipify.Maui/wwwroot/lib
git rm --cached Clipify.Maui/wwwroot/css/*.min.css
git rm -r --cached Clipify.Maui/wwwroot/temp
这些命令会移除已提交的文件,但不会删除本地文件
但我这样做了之后还是不行,git push 的时候还是很慢
分析原因
那么问题来了,为什么 git rm --cached
没用呢?
原因是 git rm --cached
只会从当前 commit(工作区)中移除指定文件的 Git 跟踪,它不会修改过去的提交记录
它解决的是「现在开始不要再跟踪」的问题, 但历史上它已经跟踪过的文件,Git 还会一直保留在对象数据库(.git/objects
)里
我在前面几个 commit 已经把 Clipify.Maui/wwwroot/lib 这类文件夹提交进去了
所以这个命令对于这个场景来说是没用的😂
简单来说,Git 是个版本管理工具,它不会忘记 你历史上做过的提交,哪怕现在 git rm --cached
移除了 lib/
文件夹
Git 仍然记得之前在第 N 次 commit 时曾经加入过它,所以 .git
目录依然保存了那些 大 blob 文件 ,push
时照样要传。
解决方法
那么如何解决呢?
以前看到的方法是编写脚本,循环从每个 commit 里删除已提交的文件
现在不用这么麻烦了,有了 git-filter-repo 工具,这是一个 python 写的可以用来重写 git 历史记录的工具
https://github.com/newren/git-filter-repo
感谢 scoop ,让我在 Windows 上也能获得类似 Linux/MacOS 类似的软件安装体验
bash
# 安装 Git Filter Repo
brew install git-filter-repo # macOS
scoop install git-filter-repo # Windows
# 或者用 Python 安装
pip install git-filter-repo
使用方法
bash
git filter-repo --path Clipify.Maui/wwwroot/lib/ --invert-paths --force
这个命令会彻底删除历史中所有与该路径相关的文件和提交记录
重写整个 Git 提交历史 之后,仓库大小会明显减小 ,git push
更快,历史提交中指定文件将完全移除 。可能需要使用 --force
强制推送代码。
经过这一通操作之后,我再使用 git push 提交明显快了很多。
拓展:如何分析git提交历史里的大文件
用 [git rev-list
+ git verify-pack
] 可以找出 Git 提交历史中的大对象(大文件)
不过 git 原生的命令比较复杂
我还是选择借助工具的力量,这次是 git-sizer 工具
git-sizer是 GitHub 官方出的工具,用于分析 Git 仓库大小、提交体积等问题。
bash
brew install git-sizer
# or
scoop install git-sizer
# or
cargo install git-sizer
PS:再次感谢 scoop !
直接在项目根目录下执行 git-sizer
即可
这个工具会输出以下信息:
- 最大的提交
- 最大的 blob(文件内容)
- 最大的目录
- 含大文件的分支
- 是否存在历史中隐藏的肥胖对象(hidden bloats)
我使用这个工具生成的结果是这样
Processing blobs: 2448
Processing trees: 218
Processing commits: 42
Matching commits to trees: 42
Processing annotated tags: 0
Processing references: 3
| Name | Value | Level of concern |
| ---------------------------- | --------- | ------------------------------ |
| Biggest objects | | |
| * Trees | | |
| * Maximum entries [1] | 1.40 k | * |
[1] 77b7ff2aa0456193bee83eebe9dfb76ebd4f35ac (2d9cc135f1aff0863ce2ef8ceff3cbf6984ee499:Clipify.Maui/wwwroot/lib/font-awesome/svgs/solid)
这样就能很方便定位到最大的文件,给 git 仓库瘦身~