上个月帮同事收拾过一个烂摊子，他把配置文件里的测试地址改成了线上地址，一条git commit加git push直接甩上去，等发现的时候已经是第二天早上。他第一反应是手动去改回来再提交一次，结果越改越乱，因为中间还夹着另外两个人的提交。这种情况其实每天在无数团队里上演，涉及到的就是 git 版本回退这件看起来简单、真动手却容易翻车的事。
我写这篇东西，是想把 git 版本回退这条线上的东西一次讲透：文件级别的恢复怎么做，还没提交的错误怎么撤，已经提交甚至已经推送到远端的错误怎么收场，以及最坏情况下把数据从对象库里捞回来的办法。无论你是刚装完 git、连暂存区都还没搞明白的新手，还是用了几年但每次回退都靠搜命令、搜完还得祈祷的老手，这篇里的思路和参数选择应该都能直接用上。全文基于我自己的实际踩坑经验，命令都在 Git Bash 里实跑过，涉及取舍的地方我会把"为什么"讲清楚，而不是甩一堆命令让你自己猜。
1. 回退之前，先把 Git 的三层结构和引用关系理清楚
很多人回退出问题，根本原因是没搞清数据到底待在哪一层。你敲下的每一条回退命令，作用对象其实只有三种：工作区的文件内容、暂存区里的索引记录、版本库里的提交对象。搞清这三者谁被改、谁没被改，判断命令该不该用就是几秒钟的事。
1.1 工作区、暂存区与版本库：数据存在哪一层
工作区就是你当前能看到、能编辑的那一堆文件。它不受 git 管理，你拿记事本随便改，git 不会拦你，它只在执行git status或者git diff的时候拿工作区跟别的东西比一比。
暂存区（也叫索引）是个很特殊的地方，它在.git/index里存了一份文件快照的清单。平时的git add就是把工作区的内容写进这一层。很多人把暂存区理解成"待提交列表"，其实它更像一张取景框，你决定哪部分画面进到下一张照片里。
版本库则是.git/objects里的一堆对象，每次git commit都会生成 tree 对象和 commit 对象，把它们永久钉在那个时间点上。所谓"回退"，绝大多数时候不是把对象删掉，而是把某个引用（HEAD 或者分支）挪到另一个提交上。对象一直都在，这就是后面 reflog 能救命的原因。
顺带说一个实际会踩的点：你在 IDE 里看到文件"变了"，IDE 显示的可能只是工作区跟索引的差异，跟"有没有提交"是两回事。很多人看到 IDE 侧边栏没有变化标记，就以为改动已经保存进历史了，其实只是git add过而已。
1.2 HEAD、分支引用与提交对象：为什么"回到过去"不会丢数据
HEAD 是一个指针，正常情况下它指向某个分支名，分支名又指向某个 commit。你执行提交时，git 做的事情是新建一个 commit，让当前分支指向它，HEAD 自动跟着走。回退的本质就是让这个指针往回挪。
这里有个关键认知：commit 对象一旦生成，除非你做垃圾回收（git gc且过了宽限期），否则它不会消失。指针挪走了，对象还在。这带来两个特别实用的结论：第一，git reset --hard看起来"删掉了"的东西，通常还能捞回来；第二，你以为删掉的分支，只要 reflog 里还有记录，就一定能恢复。
还有个细节值得记住，git 会同时维护ORIG_HEAD、FETCH_HEAD、MERGE_HEAD这些特殊引用。在你做了一次危险的 reset 或者 merge 之后，ORIG_HEAD会记录操作前的那个提交，算是一层简易保险。只不过它只保留最近一次，连续做两次危险操作就容易覆盖掉，所以真正靠谱的兜底还是 reflog。
1.3 reset、revert、restore、checkout 的职责边界
这四个命令是回退场景里最容易被混用的。它们不是同一个东西的不同写法，处理的对象和产生的结果完全不同。我把日常会用到的判断整理成一张表，遇到具体需求的时候按表查就行。
| 命令 | 主要作用对象 | 是否改动历史 | 典型用途 |
|---|---|---|---|
git restore | 工作区 / 暂存区 | 否 | 撤销未提交的修改、撤销 add |
git checkout | 工作区 / 索引，也可切分支 | 否 | 老版本 git 的通用写法，新版逐步被 restore/switch 取代 |
git reset | 暂存区 / HEAD 指针 | 是（本地） | 撤回提交、重排暂存内容 |
git revert | HEAD 指针（新增提交） | 否（新增反向提交） | 已推送的历史需要撤销 |
git commit --amend | HEAD 指向的提交 | 是（本地） | 改提交信息、补漏文件 |
判断顺序我自己的习惯是这样：先问"改的是文件还是提交"，再问"这段历史有没有推给别人"。改文件就走restore，改提交且没推就走reset或amend，改提交且已经推了就老老实实revert。这三步问完，基本不会选错命令。
2. 动手前的环境准备与最小配置
回退操作对环境的依赖其实很低，但配置不到位会让你在关键时刻看不清差异、看不懂日志，判断就跟着错。花十分钟把这几件事做完，后面每次回退都能少猜很多。
2.1 Git 安装与首次配置：三行命令搞定身份问题
Windows 上最省事的做法是装 Git for Windows，一路默认下一步，装完自带 Git Bash。如果你习惯用图形界面，TortoiseGit（也就是常说的"小乌龟"）配合 Git for Windows 一起装，安装顺序是先装 Git 再装小乌龟，否则小乌龟找不到 git 可执行文件。装完之后git --version能打印版本号就算通了；如果提示无法将"git"项识别为 cmdlet、函数、脚本文件或可运行程序的名称，八成是环境变量里没把 git 的 bin 目录加进去，重装一遍并勾选"从命令行和第三方软件使用 Git"通常就解决了。
身份配置这三行是必须的，不配的话第一次提交会直接报错：
git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global core.autocrlf true第三行在 Windows 上很关键。它控制换行符转换，不配的话团队协作时会出现"整个文件都变了但实际内容没变"的假差异，回退的时候特别容易误判。另外，core.quotepath建议设成 false，否则中文文件名在git status里会显示成八进制转义，回退某个中文文件的时候你连文件名都复制不出来：
git config --global core.quotepath false git config --global core.ignorecase false2.2 让 diff 和日志更可读：别名与参数优化
回退之前必须看清差异，看清差异就得让 diff 的输出符合你的阅读习惯。我给常用的几个配置和别名：
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit" git config --global alias.unstage "reset HEAD --" git config --global alias.last "log -1 HEAD --stat"配好之后git lg一眼就能看到分支走向，找哪个提交回退特别方便。git unstage <file>是撤销暂存的快捷写法，比记完整命令省事。
再说一个你可能在 IDE 日志里见过的参数串：git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks status。这是很多人打开 Visual Studio 或者 IntelliJ IDEA 之后，在版本控制输出窗口里看到的调用。拆开看并不神秘：diff.mnemonicprefix=false让 diff 的路径前缀统一显示成a/、b/，而不是根据操作类型变成i/、w/、c/，这样 IDE 解析输出更省事，人看着也更一致；core.quotepath=false就是我们上面说的中文路径问题；--no-optional-locks是让 git 在执行只读命令时不要去抢索引锁，避免后台 IDE 频繁扫描的时候和你的命令行操作打架。了解这几个参数的好处是，当你在 IDE 里点了"回退"却没生效，就能去输出窗口对照看真实命令是什么，而不是干瞪眼。
2.3 命令行、TortoiseGit 与 IDE：三种入口怎么选
命令行适合精确操作，尤其是 reset、reflog 这类需要看清每个参数含义的场景，参数写错一个字母结果天差地别。TortoiseGit 适合日常看日志、看某次提交改了哪些文件，它的"显示日志"右键菜单能直接看到图形化的分支树，找历史提交比翻命令行舒服。IDE 里的版本控制面板适合单文件级别的撤销，右键一个文件选"回滚"很快，但涉及提交级别的重排，我建议还是回到命令行，因为 IDE 的封装会隐藏关键参数，你不知道它到底用的是--mixed还是--hard，出了事不好判断。
一个折中的用法是：用图形工具定位到具体的 commit hash，复制出来，回到命令行执行回退。这样既有图形界面的直观，又保留了命令行的可控性。
3. 文件级恢复：只坏了几个文件，不用大动干戈
绝大多数"我搞砸了"的场景其实没到提交级别，只是某个文件被改坏、被删、被误加到了暂存区。这类问题处理起来最快，也最不容易产生副作用，因为整个过程中 HEAD 指针完全不动。
3.1 工作区文件误删、改错的还原
场景很典型：你在编辑器里一通操作，把某个文件改得面目全非，ctrl+z 又撤不回来了。只要这个文件的内容曾经提交过，一条命令就能还原：
git restore <file> # 从暂存区恢复工作区 git restore --source=HEAD <file>老版本 git 里对应的是git checkout -- <file>，现在还能用，但restore语义更清楚，checkout那个--是为了防止分支名和文件名混淆的写法，容易忘。
这里有个细节要注意：git restore <file>是从暂存区恢复工作区，如果这个文件压根没git add过，暂存区里那份就是上次提交时的样子，所以结果和从 HEAD 恢复是一样的。但如果文件已经git add过，暂存区里存的是你 add 时候的内容，git restore <file>会还原到那个版本而不是最新提交。想明确指定来源就用--source。
我自己常用的场景是"只还原一个文件，其它改动留着继续改"。比如说我一个提交里改了五个文件，其中两个改错了，我只需要对那两个文件执行 restore，其它三个照常提交，互不影响。这是文件级操作的最大优势，粒度足够细。
3.2 把加错的文件从暂存区撤下来
git add手滑把不该提交的文件加进去了，比如本地调试用的配置文件、日志文件、编译产物。这时候别急着 reset，只是想把文件从暂存区挪出来，工作区内容一点不想动：
git restore --staged <file> # 推荐写法 git reset HEAD <file> # 老写法，效果等价这两条命令只会把文件从暂存区移出，工作区的改动原封不动保留。你可以理解成把取景框里的东西拿出来，但物体本身没动。
顺便提一句撤销整个暂存区的写法：git restore --staged .或者git reset，后面不跟路径就作用到全部。用之前先git status确认一下要撤的范围，尤其是当暂存区里混着好几个不同类型改动的时候，一股脑撤掉再重新 add 一遍，往往比挑挑拣拣更稳。
注意：
git reset --hard和git reset完全是两回事。前者会连工作区一起清空，后者只动暂存区。手快敲错的代价是丢掉没提交的改动，这种错误在没有 reflog 保护的情况下基本找不回来，因为未提交内容从不进入对象库。
3.3 只把某个文件退回历史某个版本
有时候你要的不是"撤销当前改动"，而是"这个文件的内容回到三天前那次提交的样子"。命令是：
git restore --source=<commit> -- <file> git checkout <commit> -- <file> # 等价的传统写法比如git log -- config/app.yml找到那个正常版本的 hash 是a1b2c3d，那么git restore --source=a1b2c3d -- config/app.yml就能把这个文件的内容拉回到那个版本，并且自动放进工作区和暂存区。注意它只改这一个文件，其它文件不受任何影响，HEAD 也不会动。
这条命令我常用在两个地方。一是排查问题时，把配置回退到某个正常状态做对比测试；二是线上出故障后，只想快速把出问题的那个文件先改回去止血，其它的改动后面再慢慢处理。做完之后记得 commit 一条新提交，否则下次别人拉代码还是错的。
如果你更想直接看历史的完整内容、手动复制几行出来，用git show a1b2c3d:config/app.yml把内容打到终端就行，不会动任何文件。这个只读操作在排查场景里更安全。
3.4 文件早就被删了，怎么从历史里翻出来
有一种情况更棘手：文件已经被删除，而且删除的那个提交可能过了好几周，你连它叫什么名字都记不太清了。这时候需要靠日志搜索：
git log --diff-filter=D --summary # 列出所有被删除的文件 git log --diff-filter=D --name-only --oneline | grep 关键词 git log --all --full-history -- "**/文件名*"第一行会把所有删除操作和对应的文件名列出来，第二行用关键词过滤。第三行的写法稍微特殊，--all让 git 在所有分支里找，--full-history要求它不要因为历史简化而漏掉某些提交，**/文件名这种通配写法能匹配任意目录层级下的同名文件。这几种组合我基本都试过，最麻烦的情况是文件被重命名之后又删除，那就得先用git log --follow -- <当前路径>把改名历史还原出来，再顺藤摸瓜找到删除点。
找到删除前的最后一个 commit 之后，用上面 3.3 的命令把它恢复出来就行。恢复出来的文件会带着删除前的内容，等于一次完整的"从坟墓里挖出来"。
4. 提交级别的回退：写错信息、提交早了、提交多了
到了提交这一层，事情就变得复杂一些，因为你要动的是历史记录本身。动历史之前必须先回答一个问题：这些提交有没有推到共享分支上。答案不同，方案完全不同。
4.1 git commit --amend：只改最近一条，别越界
--amend干的事情是把当前暂存区的内容合并进最近一次提交，然后生成一个全新的 commit 替换掉旧的。典型用法有两个：
git commit --amend -m "修正后的提交信息" git add forgotten-file.txt git commit --amend --no-edit第一个是改提交信息，第二个是把忘记加的文件补进上一次提交，--no-edit表示信息不改。执行完之后，git log里看到的还是"一条"提交，但它的 hash 已经变了。
这里最容易踩的坑是：--amend只能改最近一次。有人以为可以git commit --amend去改三条之前的提交，结果发现命令报错或者改错了地方。要改更早的提交，就得用交互式 rebase，命令是git rebase -i HEAD~3，把想改的那条前面的pick改成edit或者reword。这个操作风险等级高不少，涉及重排整个历史行，如果这期间有别人从你的分支拉了代码，冲突会很难受。
还有个时间点要记牢：--amend之后如果这个提交之前已经 push 过，那么新的提交和远端的旧提交就分叉了，直接 push 会被拒绝，需要强制推送。所以我的习惯是，只要这个提交在别人的机器上出现过，就坚决不用--amend，改用revert或者补一条新提交。
4.2 git reset 的三种模式，选错就是灾难
git reset是回退提交的主力，也是事故高发区。它有三种模式，区别在于"撤销 HEAD 指针"这一步之外，还动不动暂存区和工作区。
| 模式 | HEAD 指针 | 暂存区 | 工作区 | 适用场景 |
|---|---|---|---|---|
--soft | 回退 | 保留改动 | 保留改动 | 想重新组织提交，把几个提交并成一个 |
--mixed（默认） | 回退 | 重置 | 保留改动 | 提交内容有问题，想重新 add 一遍 |
--hard | 回退 | 重置 | 重置 | 彻底放弃这段改动，回到某个干净状态 |
我的选择逻辑是：想保留全部改动重新提交，用--soft；想保留文件内容但重新挑选哪些进暂存区，用--mixed；确定这些改动一个都不要了，才用--hard。
举个真实例子。我曾经在一个分支上连提了三个 commit，内容都是给同一个功能做的一点点调整，review 的时候被要求合成一条。做法是先记下最前面那个提交的 hash，或者用HEAD~3表示回退三步：
git reset --soft HEAD~3 git status git commit -m "完整的功能实现"--soft的好处是三个 commit 的文件改动全部原样留在暂存区，你直接重新提交就行，不会有任何内容丢失。如果用--mixed，改动会掉到工作区，还得重新git add，多一步；如果用--hard，三个提交的内容就全没了，只剩 reflog 能救。
再说一个参数计算上的细节。HEAD~3和HEAD^3不是一回事。~表示沿着第一父提交往上数几代，^表示第几个父提交，合并提交才会有多个父提交。日常回退用~n就对了，HEAD~1和HEAD^等价。写HEAD~3表示回退到当前提交往前数三代的那个提交，也就是丢弃包含当前在内的三个提交。
4.3 回退之后想反悔：ORIG_HEAD 是第一道防线
reset --hard敲下去之后大脑一片空白，这种体验相信不少人有。先别慌，git 在大多数危险操作后都会把操作前的 HEAD 存进ORIG_HEAD。你可以这样试：
git reset --hard ORIG_HEAD如果刚刚那次危险操作没有被后续操作覆盖，这条命令能把你直接拉回来。ORIG_HEAD的存在感很低，但关键时刻真的能救命，值得记一下。
不过它只有一份，连续做两次危险操作就会被覆盖。更可靠的兜底是git reflog，这个放到第 6 节详细讲。这里先建立一个概念：只要对象还在，丢失的提交就找得回来，reset --hard丢失的只是指针位置，不是数据本身。
4.4 git revert：生成一条反向提交，而不是抹掉历史
revert和reset的思路完全相反。reset是时光倒流，让历史里那条提交好像从没发生过；revert是承认它发生过，然后新提交一条内容相反的改动去抵消它。
git revert <commit> git revert --no-commit <commit> # 只改工作区，不自动提交 git revert -m 1 <merge-commit> # 撤销一个合并提交，-m 1 表示保留第一父提交那条线最后那条撤销合并提交的写法值得单独说一下。合并提交有两个父，-m 1的意思是"以第一父提交（通常是你合并进来的目标分支）为主线，把另一条线带来的改动全部抵消"。这个参数不写就会报错，因为 git 不知道该以哪条线为基准。撤销合并是个高级操作，撤销之后再想把这条分支合并回来会遇到麻烦，因为 git 会认为这个分支的改动已经"被合并过"了，后面的合并可能什么也不做。遇到这种情况通常需要revert掉那条 revert，或者用git rebase --rebase-merges重新处理，比较绕。
revert的最大价值在于它对共享历史友好。因为它只是新增提交，不改变已有提交的 hash，别人拉代码不会有任何冲突，push 也不需要强制推送。凡是已经推到公共分支的提交，我基本都走revert这条路，哪怕它会在日志里留下"撤销某某"这么一条记录，看起来不够干净，但安全。
5. 已经推送到远端之后的回退与团队协作
本地怎么折腾都是自己的事，一旦涉及远端，回退的后果就从"影响我一个人"变成"影响所有拉这个分支的人"。这一节的重点不是命令，而是判断和约定。
5.1 为什么远端回退要格外小心
远端分支的本质是"大家约定的一个共同基准"。你用reset加强制推送把远端也倒回去，等于单方面改了这个约定。其他同事本地可能已经基于旧提交做了新提交，他们下次 pull 的时候就会遇到分叉，要么被迫处理合并冲突，要么不得不放弃自己的本地修改。如果这个人不太懂 git，最常见的反应是直接删掉自己的本地分支重新拉，那他没推的改动就全没了。
所以在我待过的团队里有个不成文的规矩：主干分支和发布分支永远只允许revert，不允许强制推送；只有个人特性分支可以随意 reset。这个约定的好处是所有人都知道历史只会前进，不会出现"昨天拉的代码今天 hash 全变了"这种事。
5.2 强制推送前的自保动作
如果确实需要改写远端历史，比如个人分支上提交了一堆乱七八糟的调试信息，想整理干净再推。这时候如果必须强制推送，用--force-with-lease而不是--force：
git push --force-with-lease origin feature/xxx两者的区别在于，--force是不管三七二十一直接覆盖远端，--force-with-lease会先检查远端当前指向的提交是不是你本地记录的那个，如果不是（说明有别人推过东西上来），就直接拒绝。这个检查能挡住绝大多数"覆盖掉同事提交"的事故。
推送之前还有两个自保动作值得养成习惯。第一，先把当前状态打个备份分支：git branch backup-20240601，这样即使后面操作乱套了，也能从备份分支捞回来。第二，把 reflog 或者当前分支的 hash 记在便签上，git rev-parse HEAD就是当前提交的完整 hash。
注意：备份分支不要留着太久。有些团队的分支列表里堆了几十个 backup 开头的老分支，既影响别人查找，也容易被误推。确认没问题后及时删掉。
如果远端设了分支保护，强制推送会直接被服务器拒绝，报错里通常有protected branch之类的字样。这不是坏事，说明有人提前给你设了护栏。
5.3 反悔的反悔：撤销一条 revert
revert之后发现撤错了，想恢复，思路也是revert——把那条 revert 提交再 revert 一次。因为 revert 提交本身就是一条普通提交，它记录的是"把 A 的改动反向应用"，那么再对这条反向提交做一次 revert，等于把 A 的改动又应用回来。
git log --oneline -5 # 找到那条 revert 提交的 hash git revert <revert-commit-hash>这种方式在共享分支上是安全的，因为它同样只新增提交，不改历史。代价是日志会变得有点像绕口令，一条"撤销了撤销某某功能的提交"的记录。我的做法是提交信息写清楚，比如Revert "Revert '调整订单超时时间'"，并且在提交正文里说明为什么又改回来，给后来看日志的人留个线索，不然半年后自己都看不懂。
6. 最后的兜底：reflog 与悬空对象
前面所有操作里，最让人安心的其实不是某条命令，而是 reflog 这个东西的存在。理解了它，你在做任何回退操作的时候心态都会不一样，因为你知道最坏情况下还有退路。
6.1 reflog 到底记录了什么
reflog 记录的是 HEAD 和各个分支引用每一次移动的历史。你每做一次 commit、reset、checkout、merge、rebase，它都会在里面写一行，包含旧 hash、新 hash、操作类型和时间。执行git reflog或者git reflog show HEAD就能看到：
a1b2c3d HEAD@{0}: reset: moving to HEAD~2 9f8e7d6 HEAD@{1}: commit: 添加订单校验 5c4b3a2 HEAD@{2}: commit: 修复支付回调注意它是本地记录，跟着你的仓库走，不会被 push 到远端，别人也看不到。默认情况下这些记录保留 90 天，不可达的对象（就是没有引用指向、但 reflog 里还留着的提交）保留 30 天。所以"昨天删的东西今天还能救"是有保障的，只要期间没手动跑过激进的 gc。
用法非常直接：找到你想回到的那一行，记下 hash，然后git reset --hard <hash>或者git checkout <hash>看一眼再决定。比如不小心reset --hard退过头了，git reflog里通常第一行就是刚才那次 reset 操作，第二行就是 reset 之前的 commit，直接 reset 回去就行。
6.2 误删分支、reset 过头之后的抢救路径
分支被删了，而且删的时候用的还是-D，很多人以为彻底没了。其实分支只是一个指向 commit 的标签，删标签不等于删提交，只要 reflog 里还有那个分支的记录：
git reflog # 找到被删分支最后一次的 commit hash git branch 恢复的分支名 <hash>或者直接git checkout -b 新分支名 <hash>，效果一样。关键是别在删完之后跑git gc --prune=now这类命令，那会把不可达对象真的清掉。
另一种常见情况是git reset --hard退太多步。处理思路和上面一样，先git reflog，找到退之前的位置，resize 回来。如果 reflog 也找不到（比如换了台机器、或者本地仓库是全新 clone 的），那就只能看远端还有没有，git log --all --oneline扫一遍所有分支，或者到 GitLab、Gitee 这类平台的事件记录里翻一翻。
6.3 用 fsck 找出悬空提交
有些极端情况 reflog 里也翻不到，比如引用被清理过，但对象其实还躺在对象库里。这时候可以用底层命令扫一遍：
git fsck --lost-found git show <dangling-commit-hash>--lost-found会把找到的悬空对象写进.git/lost-found/目录，悬空提交放在commit/子目录里。你逐个git show看看内容，找到需要的那条，再用git branch把它挂回一个分支上。
这个操作我实际用过两次，一次是同事在 rebase 出错后直接把.git里的临时引用删了，一次是某个仓库做过手工修复。频率很低，但知道有这条路，心里踏实。它也是理解 git 存储模型最好的方式之一：你亲眼看到提交对象在没有任何引用指向它的时候依然存在，就能真正理解"git 回退丢的是指针不是数据"这句话。
7. 常见报错速查与避坑清单
最后把这几年遇到的高频报错和我自己总结的注意事项整理出来，回退出问题时对照着看，多数情况能快速定位。
7.1 高频报错对照表
| 报错信息 | 常见原因 | 处理方式 |
|---|---|---|
fatal: not a git repository | 当前目录不在任何仓库里，或者.git被删 | cd到正确目录，或从远端重新 clone |
error: pathspec ... did not match | 文件名写错、路径层级不对、中文路径被转义 | 开core.quotepath=false，用git status复制准确路径 |
Your local changes would be overwritten | 目标文件有未提交改动，回退会覆盖 | 先 commit 或 stash，再执行回退 |
Updates were rejected because the remote contains work | 远端有你本地没有的提交 | 先 pull --rebase，或确认后再考虑强制推送 |
fatal: refusing to merge unrelated histories | 两个仓库历史没有共同祖先 | 确认情况后用--allow-unrelated-histories |
detached HEAD | checkout 到了具体 commit 而不是分支 | 想保留改动就git switch -c 新分支，想放弃就切回原分支 |
Cannot do a soft reset in the middle of a merge | 合并冲突未处理完就想 reset | 先git merge --abort或解决冲突 |
login failed. check api token or gitlab version | 认证凭据问题，不是回退问题 | 重新配置凭据或使用免密方式 |
detached HEAD这个状态特别需要提醒。你git checkout <commit>去看历史版本的时候，HEAD 就会处于游离状态，这时候提交的代码不属于任何分支，切走之后就很容易找不到。如果只是看看，看完直接git switch -切回原分支就行。如果想在历史版本基础上干活，第一件事就是git switch -c 临时分支名给它建个分支。
7.2 我踩过的坑与实操心得
第一条心得是关于时机的。回退的最佳时机是"刚发现错误、还没做其它操作"的时候，越早处理越简单。很多人发现提交错了，先手忙脚乱地去改文件、又提了一条、又 rebase 了一下，结果历史被搅成一团，本来一条revert能解决的事情变成要花半小时理清。所以我的建议是发现错误先停手，git log和git status看清楚了再动。
第二条是关于人心的。回退操作里最危险的不是命令本身，而是"我以为我懂了"。reset --hard这个命令被我列为最需要敬畏的一条，每次敲之前我都会多看一眼git status，确认工作区里没有我没保存的东西。养成"危险命令先看一眼状态"的习惯，能避免大部分后悔。
第三条是关于协作沟通的。如果回退涉及别人正在使用的分支，先打个招呼比事后解释成本低得多。我经历过一次同事直接强推主干，导致另一个人的半天工作要重新处理，最后虽然数据都找回来了，但浪费的时间和信任是实打实的。现在我的做法是，凡是涉及公共分支的历史改动，先在群里说一句"我要 revert 某条提交，影响范围是什么"，几分钟的事。
第四条是关于备份的。在不确定的操作之前建一个临时分支，这个动作只要三秒钟，却能在最坏情况下省几个小时。我的命名习惯是bak/日期-用途，做完确认没问题就删掉，不留垃圾。
最后一条是关于工具选择的。图形化工具在"看"这件事上确实强，日志树、文件差异展示得比命令行清楚，我能理解很多人习惯用 TortoiseGit 或者 IDE 面板。但涉及 reset、rebase、reflog 这些需要精确控制的场景，还是建议回到命令行，看清楚每个参数的语义。一个比较稳妥的组合是用图形工具定位和确认，用命令行执行。这两者搭配起来，既直观又可控，是我这些年用得最顺的方式。
