Git 三大高阶实战：rebase、cherry-pick、bisect 一次讲透，冲突排查也能现场处理

开场：OK so，今天我们把 Git 的“高阶三连”直接打穿

哈喽各位，我是 eccfy。接下来这期不是讲“Git 是什么”，而是直接上手：rebase、cherry-pick、bisect 到底怎么用，什么时候用，冲突来了怎么拆。你可以把它理解成三个按钮：整理提交历史、单独搬运修复、快速定位问题提交。我在本地仓库里跑给你看，边操作边解释，别眨眼。

先说一句大实话：这些技巧不是为了炫技，是为了在团队协作里少踩坑。比如你从主干拉了个分支，改了 5 个 commit，结果主干又更新了 20 次；或者你只想把线上修复从 A 分支搬到 release 分支；再或者“昨天还好好的，今天一合并就炸了”——这三个工具就是救场的。

Chapter 1：rebase 不是“重写历史吓人”，而是把提交排整齐

OK so，先看最常见的场景。你当前在 feature 分支，想把它接到最新 main 上。直接命令：

git fetch origin
git rebase origin/main

这一步的效果是：把你本地分支上的提交“挪到”最新 main 后面，看起来像你一直基于最新代码开发。好处是提交历史更线性，review 时很清爽；坏处是会改写 commit hash，所以只适合你自己本地分支，别拿去乱改别人正在用的公共分支。

我这边模拟一个冲突给你看：当终端停在 CONFLICT，先别慌。你打开文件，找到 <<<<<<< 标记，手动保留正确逻辑，然后：

git add .
git rebase --continue

如果你发现这波改乱了，立刻撤：git rebase --abort。这就是 rebase 的底层思路：能继续就继续，不能继续就回到起点。

实战提醒：如果你在团队里做“Git rebase 教程”，一定强调两个习惯：一是 rebase 前先 git status 看工作区干不干净；二是不要对已经 push 且别人基于它开发的分支做 rebase 后强推，除非你们约定好流程。

Chapter 2：cherry-pick 像“精准搬运工”，只搬你要的那个提交

接下来是 cherry-pick。它最适合这种情况：bug 修复已经在 dev 分支上完成，但线上 release 分支还没合并完整功能，你只想把那个修复带过去。先找提交号：

git log --oneline

比如看到一个提交 3f2a9c1 fix: null pointer in login，那就：

git checkout release
git cherry-pick 3f2a9c1

现场效果很直观：这个提交会被复制到当前分支，生成一个新的 commit。注意，它不是移动，是复制。所以别误会成“把原分支删掉”。如果有多个连续提交，你也可以一次选一段，但新手建议先单个 cherry-pick，出错更好回滚。

我在测试里常用的判断方法是：搬完后立刻比对差异。

git diff release~1 release

如果差异只包含你要的修复，那就稳了。这个步骤在“Git cherry-pick 怎么用”搜索里特别常见，核心就是：只搬补丁，不搬无关功能。

Chapter 3：bisect 是排查神器，二分法把坏提交抓出来

OK，现在进入最爽的部分：bisect。假设你现在知道“当前版本有 bug”，但你不知道是哪一次提交引入的。别一个个翻，直接二分查找。

git bisect start
git bisect bad
git bisect good v1.4.2

Git 会自动跳到中间某个提交。你这时运行测试或复现脚本，比如：

npm test
或者
pytest -q

如果当前版本有问题，就执行：

git bisect bad

没问题就执行：

git bisect good

我做过一次真实排查：一个接口响应从 120ms 飙到 980ms，手工看了 14 次提交；用 bisect 后，5 次内就锁定是某次缓存 key 变化导致的。也就是说，从线性排查变成对数排查，在大仓库里特别值。

结束后别忘了：

git bisect reset

Chapter 4：怎么选、怎么练、怎么验证真的学会了

给你一个超实用的对照表：

rebase：整理本地提交顺序，适合把 feature 分支接到最新主干。
cherry-pick：只拿某个修复提交，适合 hotfix 回灌到 release。
bisect：定位“哪个提交引入了 bug”，适合性能退化和逻辑回归。

如果你想自测，直接做这个小练习：新建一个仓库，提交 6 次；故意在第 4 次引入 bug；用 git bisect 找它；再把第 2 次提交用 cherry-pick 搬到另一个分支；最后对 feature 分支做一次 rebase。这套流程跑通，你基本就不是 Git 初学者了。

如何验证真的生效：rebase 后用 git log --oneline --graph 看历史是否变线性；cherry-pick 后用 git show --stat 看是否只带入目标改动；bisect 后看终端是否输出唯一嫌疑 commit，再用对应版本回归测试确认问题复现。

如果你想继续看我把 Git 冲突处理、revert/reset、reflog 也做成“视频脚本式实战”，评论区告诉我。最后补一句，想先找个现成工具快速上手的，也可以看看 roxi.cc，但这些命令本身你完全可以免费、手动、直接练起来。