误删分支后怎么找回

学完这篇你会掌握什么

• 理解 误删分支后怎么找回 的核心作用和适用场景
• 掌握 误删分支后怎么找回 的基本用法和常用参数
• 分支删掉后，通常先确认是名字没了还是提交也不可达了，再用 reflog、merge-base 和旧引用位置把分支接回来。
• 理解 先别把"分支没了"和"提交没了"混在一起 相关的概念
• 掌握 第一轮检查 相关的操作
• 知道在什么场景下使用该命令，什么场景下避免使用

先想一个问题

你刚刚在 Git 里做了一个操作，结果发现不是你想要的效果——甚至可能弄丢了提交。这种情况不是第一次了，你想建立一套可靠的方法来应对各种误操作场景。

先别把"分支没了"和"提交没了"混在一起

reflog 历史记录

HEAD@{3}HEAD@{2}HEAD@{1}当前 HEAD 位置

新建救援分支

rescue/recover

删除分支，先消失的通常是分支名，不一定是底层提交对象。
只要还有别的引用、reflog 或最近历史能指向那些提交，恢复往往不难。

第一轮检查

git branch -a
git reflog
git log --oneline --graph --decorate --all -n 40

你要回答两个问题：

1. 这个分支只是本地删了，还是远端也没有了？
2. 它最后大概停在哪个提交上？

最常见的恢复方式

如果你在 reflog 或图里找到了那个提交，直接把分支重新建回来：

git branch feature/rescue <commit>

或者如果你想立刻切过去：

git switch -c feature/rescue <commit>

如果是远端分支还在

那问题更简单，本地只是把跟踪分支删了：

git fetch origin
git switch -c feature/name --track origin/feature/name

这种情况更像“重新建立本地入口”，不是复杂恢复。

如果你只记得大概位置

可以结合这些线索：

• 最近做过 merge / rebase / checkout 的 reflog
• 相关 PR 合并点
• git merge-base
• 历史图里的分叉点

恢复的关键不是马上找到分支名，而是先找到它最后指向的提交。

什么时候恢复会变难

下面几种情况会明显提高难度：

• 分支删掉很久了
• 没有任何别的分支或标签再引用那些提交
• reflog 窗口已经过去
• 仓库已经做过垃圾回收

所以一旦发现删错，最好立刻停下来找，而不是先继续整理仓库。

推荐动作顺序

1. git reflog
2. 找到最后一个可信提交
3. 新建 rescue/* 分支
4. 再决定是否恢复原分支名

一个经验

真正的恢复目标不是“把原名字抢回来”，而是“先把原来的工作接住”。
名字可以后改，提交位置先接住最重要。

给你的练习

1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
2. 尝试该命令的不同参数选项，对比输出结果的差异
3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

• cherry-pick 挑错提交后的恢复
• 仓库损坏后怎么恢复
• 提交丢失后怎么找回