你的截图自动化正在让你的 Git Repo 变得臃肿

Source: Dev.to

问题：截图让仓库体积膨胀

我之前为文档截图实现了自动化。每周只需运行一个命令就能重新生成 30 多个 PNG。再也不需要手动截图。生活本来很美好——直到我查看了仓库大小。

• 仓库大小： 412 MB（一个文档项目）。
• 原因： Git 会把二进制文件作为完整副本存储。每次重新生成截图——即使只改动了一个像素——Git 也会再次保存整个文件。
• 影响： 每周更新 30 张截图 → 每年约 156 MB 的历史记录。
• 后果： 新贡献者克隆仓库时需要等待；CI 流水线会下载数百兆的旧 PNG，而这些文件再也不会被查看。

解决方案：使用 Git LFS

Git LFS 用极小的指针文件（≈130 字节）替代你的图片。实际的图片存放在独立的服务器上，但检出时仍然正常工作——你几乎感觉不到差别。

一次性设置

git lfs install
git lfs track "heroshots/*.png"
git add .gitattributes
git commit -m "configure Git LFS"

你的常规 Git 工作流（git add、git commit、git push）保持不变。LFS 在后台处理路由。

迁移已有图片

git lfs migrate import --include="heroshots/*.png"
git push --force-with-lease

上述仓库在迁移后从 412 MB 缩减至 28 MB。

CI 集成（GitHub Actions）

如果在 GitHub Actions 中运行截图更新，需要在检出时启用 LFS：

- uses: actions/checkout@v4
  with:
    lfs: true

若未启用，CI 作业只会得到指针文件（130 字节的文本文件），导致截图对比步骤失败。

何时使用 Git LFS

• 不使用 LFS：如果只有少量截图且很少更改。普通 Git 完全足够。
• 使用 LFS：适用于自动化截图工作流：
  • 每周更新 30+ 张图片
  • 多人协作的团队
  • 开源项目且有大量克隆者

快速经验法则

进一步阅读

更多细节请参阅 heroshot 文档。