- 已经会基本提交和分支操作的开发者
- 想理解命令边界与风险的人
Command Reference
git-fsck 教程
解释如何用 git-fsck 检查对象库和引用的完整性。
- 知道工作区、暂存区、提交的基本关系
- 能读懂 `git status` 和简单历史图
- 误把本地整理命令用到共享历史
- 在没确认恢复路径前直接继续改写历史
一句话理解
git-fsck 用于检查对象库和引用的完整性。
什么时候适合用
- 当你需要检查对象库和引用的完整性
- 当你想把这类操作做成稳定流程而不是手工重复
- 当你需要更准确地理解 Git 在这一步到底记录了什么
基本示例
git fsck --full
读这条命令时最该注意什么
这是一条纯只读的检查命令，不会对仓库做任何修改。它会扫描对象数据库并报告损坏、悬空对象等问题。
一个更稳的实践建议
加上 --full 可以检查所有对象（包括已 pack 的），适合做全面完整性检查。--no-dangling 可以忽略悬空对象输出，让结果更简洁。
补充理解角度
- 排查"对象损坏"或"corrupt"报错时的第一步工具
- 查找悬空 blob/tree/commit，辅助恢复误删内容
- 验证迁移、克隆或打包后的仓库完整性
这条命令在流程里解决什么问题
git fsck 关注的是对象存储、pack 文件、可达性和仓库维护质量。它通常不是日常提交流程的一部分，而更像是诊断或维护工具。
典型用例
- 在怀疑仓库数据完整性有问题时，用
git fsck执行全面检查。 - 把
git fsck放进维护流程，帮助你观察 pack、对象数量和可达性状态。 - 在排查性能、体积或完整性问题时，用
git fsck补足高层命令看不到的存储细节。
图例理解
对象数据库pack 文件可达性信息
损坏报告悬空对象列表完整性状态
这条命令只读不写，可以放心运行，不会改变仓库任何状态。
特殊情况与边界
- 只读检查命令，任何时候运行都不会影响仓库状态。
--lost-found可以把悬空对象的内容写入.git/lost-found/，方便后续查看。- 悬空对象（dangling）本身不是错误，它们可能是未引用的提交、旧的 blob 等，需要结合场景判断是否需要处理。
延伸阅读
继续搭配 git status、git log、git show 一起看，通常更容易判断这条命令对历史、索引和工作区分别造成了什么影响。