知识库：Git维护与 PicGo 图床实践
知识库：Git维护与 PicGo 图床实践
本文档归档当前笔记仓库在 Git 管理和图片存储方面的实际方案，重点包括：仓库现状判断、.git 膨胀原因、继续使用 PicGo + GitHub + jsDelivr 时的低干扰优化策略，以及后续维护建议。
1. 仓库背景与当前使用方式
当前仓库路径：/Users/util6/Documents/blog-article
当前使用方式有两个核心特点：
- Markdown 笔记与配图放在同一个仓库中。
- 图片通过
PicGo -> GitHub 图片仓库 -> jsDelivr的链路上传和访问。
这意味着：
- 文字内容和图片内容都在同一个 Git 仓库内。
- 图片虽然通过 CDN 访问，但本质上仍然是 Git 仓库中的文件。
- 因此图片仍然会进入 Git 历史，
.git会持续累积这些二进制对象。
2. 当前仓库 Git 状态判断
对仓库进行检查后，可以得到几个结论。
2.1 仓库本身没有损坏，主要问题是规范性不足
当前仓库可以正常工作，不属于“坏仓库”或者“危险仓库”。真正的问题主要集中在：
- 提交信息风格不统一。
- 远程仓库配置语义不够清晰。
- 历史中混入了较大的图片、GIF、压缩包和导图源文件。
2.2 当前远程配置
当前远程情况是：
github指向 GitHub 仓库。origin既有 Gitee 的 fetch/push，又额外配置了 GitHub 的 push URL。
这种做法可以实现一次 git push origin master 同时推多个远端，但需要自己清楚：
origin已经不是单一远程。- 自动化脚本如果推
origin，会沿用这个多 push URL 的行为。
2.3 频繁提交文字笔记不是主要膨胀来源
Markdown、代码、纯文本这类内容，Git 很擅长做差异存储。
所以：
- 频繁提交笔记内容本身通常不会显著增大
.git。 - 真正导致
.git变大的主要是二进制文件，尤其是大图片、大 GIF、压缩包和源文件。
3. .git 为什么会变大
检查结果显示，.git 体积的大头来自 .git/objects/pack。
这说明：
- 膨胀主要不是工作区文件导致的。
- 主要是历史提交里已经保存下来的大对象。
典型高风险文件包括：
pngjpggifzippsdemmx
其根因是：
- Git 对文本更像存增量。
- Git 对二进制文件更像存快照。
- 同一张图如果多次覆盖提交，历史里通常会多出多份较大的对象。
需要明确：
jsDelivr解决的是访问分发问题。- 它并不解决 Git 历史膨胀问题。
4. 关于“图片留在仓库但不要进 .git”的结论
这件事在普通 Git 仓库里做不到。
只要满足下面两个条件：
- 图片仍然放在当前 GitHub 仓库里。
jsDelivr继续直接引用这个仓库里的文件。
那么图片就一定会进入 Git 历史，也一定会进入 .git。
因此最终采用的是一个现实折中方案：
- 保持当前
PicGo + GitHub + jsDelivr用法不变。 - 接受图片会进入 Git 历史。
- 通过低干扰规则尽量减缓仓库膨胀速度。
5. 在不改变现有用法下，如何尽量减小膨胀
核心策略不是“阻止图片进入 Git”，而是“减少无意义的大对象进入 Git”。
5.1 使用习惯层面的约束
建议保留以下规则：
- 优先上传压缩后的静态图。
- 能用
jpg/webp就尽量不要用大png。 - 少传
gif，尤其是大 GIF。 - 只上传最终版图片，不上传临时截图和草稿图。
- 不要把压缩包、导图源文件放进图床目录。
- 同一张图尽量少覆盖，避免二进制历史不断累计。
5.2 仓库规则层面的优化
已经对仓库做了两类低干扰优化。
.gitignore
补充了容易误进仓库的大文件与临时产物规则，例如：
*.7z
*.rar
*.tar
*.tar.gz
*.tgz
*.xcf
*.emmx
*.drawio
*.drawio.png
*.drawio.svg
chrome-capture-*.png
upload_results.json
A文章图片/upload_results.json这样可以减少临时导出物、导图源文件、压缩包误进入历史的概率。
.gitattributes
新增了 .gitattributes，把图片和压缩包等文件标记为二进制并关闭 delta 压缩：
*.png binary -delta
*.jpg binary -delta
*.jpeg binary -delta
*.gif binary -delta
*.webp binary -delta
*.zip binary -delta
*.7z binary -delta
*.rar binary -delta
*.tar binary -delta
*.gz binary -delta
*.tgz binary -delta
*.pdf binary -delta
*.psd binary -delta
*.emmx binary -delta这不能删除旧历史，但可以减少 Git 对这些文件做低收益 delta 打包的开销。
5.3 git gc 的作用边界
已经执行过一次 git gc。
结果说明：
git gc可以整理对象库。- 但不能真正删除历史中的大对象。
- 如果不重写历史，旧的大图片和大压缩包仍然会保留在
.git中。
所以可以把它理解为：
git gc是“整理箱子”。- 不是“把大件扔掉”。
6. PicGo 配置与当前图床工作流
当前图床配置已经整理到：图床配置/PicGo配置指南.md
关键配置如下：
- 仓库：
util6/blog-article-images - 分支：
main - 存储路径：
留空 - 自定义域名：
https://cdn.jsdelivr.net/gh/util6/blog-article-images@main
工作流是：
本地截图 -> PicGo -> GitHub 图片仓库 -> jsDelivr -> Markdown 引用
需要注意：
- PicGo 上传后，图片先出现在 GitHub 仓库中。
- 如果希望本地和 Gitee 也同步这部分图片，需要后续
git pull和git push。
7. 当前方案的优点与风险
7.1 优点
- 不改变原有
PicGo + GitHub + jsDelivr使用习惯。 - 保留笔记和配图在同一仓库的组织方式。
- 通过
.gitignore和.gitattributes降低了无意义膨胀。
7.2 风险
- 只要继续把图片放在当前仓库里，
.git仍会继续增长。 - 历史中的旧大对象依然存在，不做重写历史就不会真正瘦下来。
8. 后续维护建议
建议把后续维护策略固定为下面几条：
- 文字笔记可以放心频繁提交。
- 图片提交前尽量压缩，避免大 GIF。
- 临时截图和草稿图不要直接走 PicGo 上传。
- 压缩包、导图源文件、输出清单等继续通过
.gitignore排除。 - 定期关注
.git/objects/pack的体积变化。 - 如果未来
.git再次明显膨胀，再考虑是否进行一次真正的历史瘦身。
9. 相关文件索引
与本次方案直接相关的文件有：
图床配置/PicGo配置指南.md.gitignore.gitattributes
如果后续仍然坚持同仓库图片方案，那么最现实的目标就不是“图片不进 Git”，而是“只让必要的、尽量小的最终版图片进入 Git”。