Git故障排查：常见错误、冲突解决技巧、数据恢复、性能问题诊断
Git用久了，谁还没遇到过几个坑呢？说实话，我见过太多开发者在Git面前抓狂的样子了。我自己也踩过不少雷，从误删分支到合并冲突搞到凌晨三点。今天我就把这些年积累的排查经验整理出来，希望能帮你少走些弯路。
核心思路：Git故障排查其实就四个字——「别慌，先看」。大多数问题都有成熟的解决方案，关键是要知道从哪下手。
一、常见错误及应对
先说说那些你大概率会遇到的报错。嗯，我敢打赌，下面这几个你至少见过两个。
1.1 「fatal: Not a git repository」
这个错误说白了就是Git找不到仓库。我刚开始用Git时，经常在子目录里执行git命令，结果忘了初始化。解决办法很简单：
# 检查当前目录是否有.git文件夹
ls -la .git
# 如果没有，要么初始化，要么cd到正确的目录
git init # 或者 cd 到已有仓库的目录1.2 「fatal: refusing to merge unrelated histories」
这个我遇到过好几次。通常发生在你从别处复制了一个项目，然后想跟远程仓库合并。Git觉得这两个仓库「八竿子打不着」，就拒绝了。解决方案：
git pull origin main --allow-unrelated-histories加个--allow-unrelated-histories参数，告诉Git：「我知道它们没关系，但我就是要合并」。不过要小心，合并后可能会有大量冲突。
1.3 「error: Your local changes would be overwritten by checkout」
你想切换分支，但本地有未提交的修改。Git怕你把修改搞丢了，所以拦着你。我个人习惯的做法是：
# 方案一：暂存修改
git stash
git checkout 目标分支
# 切回来后用 git stash pop 恢复
# 方案二：提交当前修改（如果是有意义的改动）
git add .
git commit -m "临时提交"
git checkout 目标分支小技巧：我一般用git stash来处理临时切换分支的场景。但记得别stash太多，否则自己都忘了存了啥。
二、冲突解决技巧
冲突是Git里最让人头疼的事之一。但说白了，冲突就是两个人改了同一块代码，Git不知道该听谁的。你想想看，这其实是个「谁说了算」的问题。
2.1 冲突标记解读
当冲突发生时，Git会在文件里插入这样的标记：
<<<<<<< HEAD
这是你当前分支的代码
=======
这是合并进来的分支的代码
>>>>>>> feature-branch你需要手动决定保留哪部分，或者两者都保留。我一般会跟团队成员沟通一下，确认最终方案。
2.2 解决冲突的实用工具
别只用文本编辑器硬啃。我推荐几个工具：
- VS Code：内置的合并编辑器，可视化对比，点几下就解决了
- Beyond Compare：老牌工具，三栏对比很清晰
- Meld：免费开源，Linux上用得比较多
2.3 避免冲突的实战经验
我曾经在一个大项目里，团队20多人同时开发，冲突几乎每天都有。后来我们总结了几条规矩：
- 频繁拉取：每天至少
git pull两次，别攒一周的代码再合并 - 小步提交：每次提交只改一个功能点，别一次改几百行
- 及时沟通：如果你要改一个大家都在用的公共模块，先打个招呼
注意：千万不要用git push --force来解决冲突！我曾经见过有人这么干，结果把同事的代码全覆盖了，那场面...嗯，你懂的。
三、数据恢复
Git最牛的地方之一就是「几乎删不干净」。只要你提交过，大概率能找回来。我帮同事恢复过好几次误删的分支和提交。
3.1 找回误删的分支
如果你不小心删了一个分支，别慌。Git会保留一段时间：
# 查看所有分支操作记录
git reflog
# 找到被删分支的最后一个commit hash
# 然后基于它创建新分支
git checkout -b recovered-branch <commit-hash>reflog是个好东西，它记录了你在本地仓库的所有操作。我建议你记住这个命令，关键时刻能救命。
3.2 恢复误删的提交
有时候你git reset --hard之后发现搞错了。别急：
# 查看reflog找到你想要的提交
git reflog
# 用cherry-pick把那个提交捡回来
git cherry-pick <commit-hash>3.3 恢复误删的文件
如果你只是删了一个文件还没提交，可以用：
# 从上一个提交恢复这个文件
git checkout HEAD -- 文件名我的经验：养成定期git push的习惯。本地数据丢了还能从远程拉回来，但远程也丢了就真没办法了。
四、性能问题诊断
仓库越来越慢？别急着重建。先诊断一下问题出在哪。
4.1 常见性能瓶颈
| 问题 | 症状 | 解决方案 |
|---|---|---|
| 仓库体积过大 | git clone 很慢 | 使用浅克隆 git clone --depth 1 |
| 大文件 | git push 卡住 | 使用 Git LFS 管理大文件 |
| 分支太多 | git branch 列出几百个 | 清理已合并的分支 |
| 对象文件碎片化 | git gc 执行很慢 | 定期执行 git gc --aggressive |
4.2 诊断命令
我常用的几个诊断命令：
# 查看仓库大小
git count-objects -v
# 查看大文件
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print $3, $4}' | sort -rn | head -10
# 查看分支数量
git branch | wc -l4.3 优化建议
说实话，大部分性能问题都是「懒」出来的。我建议你：
- 每周跑一次
git gc，清理垃圾对象 - 别把二进制文件（图片、视频）直接提交到Git仓库
- 定期清理已经合并到主分支的特性分支
- 如果仓库实在太大，考虑用
git clone --depth 1做浅克隆
一句话总结：Git故障排查的核心就是「知道问题在哪，知道用什么工具」。reflog、stash、cherry-pick、gc，这四个命令用熟了，大部分问题都能搞定。
好了，Git故障排查这块就聊到这儿。记住，遇到问题先深呼吸，然后想想reflog、stash、cherry-pick、gc这四个命令。大部分坑都能填上。如果你有其他奇葩问题，欢迎来公众号找我聊聊。