记录正在发生的一切

初衷#

我做这个项目的出发点很简单：担心 GitHub 上的仓库被删库，或者作者突然删掉大量文件。哪怕是开源项目，也有被误删、冲突、被封号的风险。我不想把“关键代码”寄托在单点上，所以决定做一个可靠的本地备份工具。

心路历程#

最开始我只想做一个普通的同步备份工具：定时拉取、打包、保存到本地。实现起来很快，流程也直观——拉代码，压缩，留几份版本。

但越用越不踏实：如果作者删库，我只能得到一次“拉取失败”；如果作者大批量删除文件，本地就会被一次更新覆盖成空壳。这个场景让我警觉，于是我把工具目标从“同步”升级成“防删库”。

之后的版本，我加入了“风险检测”和“记录留存”。只要检测到仓库不可访问、或删除比例异常，就会标红提示，不再贸然覆盖本地备份。这个阶段开始，工具真正有了“守住本地副本”的能力。

现在的定位#

GitGuard 不是一个简单的同步器，而是一个“保守型的备份工具”。它的工作方式是：尽量自动化，但遇到高风险改动就谨慎处理。

关键功能#

• 定期检查仓库更新，并生成 commits 记录
• 仅对需要更新的仓库执行拉取与打包
• 7z 高压缩备份，保留最近 N 份
• 识别“删库 / 大量删除”并标红提示
• 保存状态信息，避免误覆盖有效版本

典型流程#

1. 选择备份根目录
2. 添加 GitHub 仓库地址
3. 点击“检查更新”
4. 对显示需要更新的仓库执行“拉取更新”

关键判断（防删库）#

我加入了“删库风险”判断逻辑，用来拦截以下情况：

• 仓库不可访问或被删除
• 文件删除量异常偏大
• 删除占比异常（超过阈值）

这些情况都会被标红提示，默认不继续覆盖本地备份，避免把“完好的历史版本”覆盖成“删库后的空版本”。

小结#

这个项目不是一蹴而就的。它是我从“只是同步”到“必须防删库”的过程。工具不复杂，但目标明确：一旦云端出现问题，本地仍然有完整可追溯的备份。

我希望它能帮到那些和我一样对开源仓库有依赖、但又不敢完全信任单点存储的人。