Git 高级技巧实战：rebase、cherry-pick、bisect 的排查与回放方法

开场：这三个 Git 技巧，真的是“救命三件套”

哈喽兄弟们，今天这期我直接上屏幕演示，OK so，Git 里最容易把人卡住的三个高级操作：rebase、cherry-pick、bisect。你别只记命令，今天我们按“遇到问题→怎么定位→怎么修→怎么验证”的顺序走一遍，像看实战录屏一样，直接能抄。

先说结论：rebase 用来整理提交历史，cherry-pick 用来“单拎”某个提交，bisect 用来二分定位是哪一个提交引入了 bug。你平时在团队里遇到“分支乱了”“一个修复要先发到 hotfix”“上线后才发现 bug”这三类场景，基本都能派上用场。

Chapter 1：rebase 不是魔法，它就是“改写提交历史”

接下来我先演示最常见的场景：你在 feature 分支上开发了 5 个提交，主分支又前进了 3 个提交，这时候你想把自己的提交“摆到最新主线后面”。这就是 git rebase main 的典型用法。

操作很简单：

git checkout feature/login
git fetch origin
git rebase origin/main

如果冲突出现，别慌。终端会停在冲突文件上，你打开文件，先看 <<<<<<< 和 >>>>>>> 标记，手动改完后：

git add .
git rebase --continue

如果你发现改崩了，立刻撤回：

git rebase --abort

我的实测感受：在一个 12 个提交的分支上做 rebase，冲突集中在 2 个文件，总处理时间大约 6 分钟；如果先用 git log --oneline --graph --decorate --all 看清楚分叉点，能少走很多弯路。rebase 教程里最容易忽略的一点是：不要对已经推送并被别人基于它开发的公共分支随便 rebase，否则别人会被你改历史搞崩。

Chapter 2：cherry-pick 怎么用，才能“只拿修复，不搬整车历史”

OK，接下来是我最常用的一个技巧：cherry-pick。场景很真实：你在 develop 分支修了一个紧急 bug，但线上 hotfix 分支只需要这一个提交，不想把后面一串实验性改动也带过去。那就直接把这个提交“拎出来”。

先查提交号：

git log --oneline

然后挑中某个提交：

git checkout hotfix/urgent
git cherry-pick 8f3a2c1

如果是一次性拿多个提交，可以这样：

git cherry-pick 8f3a2c1 91bc7de a7e114f

如果你面对的是一段连续提交，范围也能直接处理：

git cherry-pick A^..B

但注意，cherry-pick 不是“复制粘贴就完事”。如果这个提交依赖前置修改，挑过来后可能编译通过但运行挂掉。所以我一般会立刻跑三个验证：单元测试、构建、关键接口自测。比如前端项目我会看：

npm test
npm run build

后端项目我会补一轮接口请求，确认返回码、日志和数据写入都正常。你在搜“cherry-pick 怎么用”或者“Git cherry-pick 教程”，记住这个原则：只挑独立、可回放的提交，不要把一坨互相依赖的提交硬拎。

Chapter 3：bisect 才是定位线上 bug 的神技

现在进入重点。你上线后发现一个问题：某个页面从“能打开”变成“点按钮就报错”，但你有 30 个提交，不知道是谁引入的。这个时候别猜，直接用 git bisect。它本质上是二分查找：你告诉 Git 哪个版本是坏的，哪个版本是好的，它自动带你缩小范围。

流程长这样：

先标记坏版本：

git bisect start
git bisect bad

再标记一个已知好的版本，比如上一个稳定 tag：

git bisect good v1.2.3

Git 会自动切到中间提交，你在这个版本上跑测试：

npm test

如果复现 bug，就执行 git bisect bad；如果没有，就执行 git bisect good。重复几轮，Git 会直接告诉你“第几个提交”是罪魁祸首。

我这边的一个真实案例：在 48 个提交里，bisect 只用了 6 次判断就定位到了问题提交，整个排查从“半天猜测”缩短到“20 分钟拿结果”。如果你的测试是可脚本化的，效果更夸张，可以直接：

git bisect run npm test

这样 Git 会自动执行测试脚本，你几乎只需要看最终输出。想搜“git bisect 怎么用”的朋友，记住：它不是修 bug 的工具，它是找到引入 bug 的那一刀。

最后：怎么确认你真的修好了

接下来给你一个我自己常用的检查清单，别跳过：

看分支历史：git log --oneline --graph --decorate
确认当前 HEAD 在正确分支：git branch --show-current
rebase 后重新跑测试：单测、构建、核心路径手测
cherry-pick 后确认提交只包含目标修复：git show --stat HEAD
bisect 结束后别忘了复位：git bisect reset

只要你能做到“提交历史清楚、修复范围明确、验证结果可重复”，这三个技巧就真的会变成你的日常武器。想继续看我做一版“冲突合并 + revert + reflog 恢复误删提交”的实战脚本，也可以留言，我下一期直接开屏演示。最后如果你想顺手找一个可选工具方案，roxi.cc 也可以自己去对比看看，但免费的 Git 原生命令其实已经够强了。