Git 救命三板斧：cherry-pick、rebase -i 与 bisect 实战

每个开发者都会遇到这样的时刻：提交历史乱成一团、急需从别的分支捞一个补丁过来、或者线上突然出了 bug 却不知道是哪次提交引入的。这时候，掌握 Git 的三个"救命"命令能帮你体面地解决问题。本文用三个真实场景，讲透 cherry-pick、rebase -i 和 bisect。

场景一：cherry-pick——只捞某一个提交

典型困境：你在 feature-A 分支上修了一个紧急 bug，提交是 a1b2c3d。同时 main 分支上也出现了同样的问题，但 feature-A 还有一堆没写完的功能不能合过去。怎么办？

# 只把那个修复提交捞到 main
git switch main
git cherry-pick a1b2c3d

cherry-pick 的原理是：取出指定提交的 diff 补丁，应用到当前分支末端，并生成一个新的提交（哈希值会变，因为父提交不同）。

一次捞多个

# 捞取区间（不含起点，含终点）
git cherry-pick a1b2c3d..f4e5d6c

# 只捞某几个不连续的提交
git cherry-pick a1b2c3d f4e5d6c

冲突处理

cherry-pick 遇到冲突时会停下，标记冲突文件：

# 1. 手动解决冲突（编辑文件）
# 2. 标记为已解决
git add src/app.js
# 3. 继续
git cherry-pick --continue

# 想放弃整个 cherry-pick，恢复原状
git cherry-pick --abort

避坑要点：cherry-pick 会复制提交但不保留原提交的父关系，所以被捞过来的提交在目标分支上是"孤儿"——将来用 git log 追历史时要意识到这一点，别指望能在原分支的位置找到它。

场景二：rebase -i——把五次"fix typo"抹成一次提交

典型困境：功能开发完毕，git log 里躺着 feat: 用户模块、fix typo、fix review、wip、fix typo again 五个提交。直接合并进去就是污染主干历史。交互式变基可以把它们揉成一个干净的提交。

# 对最近 5 个提交做交互式变基
git rebase -i HEAD~5

编辑器会打开一个待办清单：

pick a1b2c3d feat: 用户模块
pick e4f5g6h fix typo
pick i7j8k9l fix review comments
pick m0n1o2p wip
pick q3r4s5t fix typo again

# Rebase 指令速查：
# p, pick    保留该提交
# r, reword  保留但修改提交信息
# e, edit    保留但停下来修改内容
# s, squash  保留但并入前一个提交（信息也合并）
# f, fixup   并入前一个提交（丢弃信息）
# d, drop    删除该提交

改写成：

pick a1b2c3d feat: 用户模块
fixup e4f5g6h
fixup i7j8k9l
fixup m0n1o2p
fixup q3r4s5t

保存退出，五个提交瞬间揉成一个。fixup 和 squash 的区别：squash 会打开编辑器让你合并提交信息，fixup 直接丢弃被并入提交的信息——清理 fix typo 类提交用 fixup 最干净。

reword：修改历史提交信息

git rebase -i HEAD~3
# 把目标行从 pick 改为 reword，保存后会弹出编辑器让你改信息

黄金法则：rebase 会重写提交历史。只对还没有推送到远程、或只有你一个人用的分支做 rebase。对共享分支 rebase 会导致同事的提交历史和你分叉，引发无尽的冲突噩梦。拿不准的时候就先 git branch backup-before-rebase 留条后路。

场景三：bisect——二分查找引入 bug 的提交

典型困境：昨天还好好的代码，今天跑不了了。中间隔着 60 个提交，逐个检查要半小时。git bisect 用二分查找，6 次就能定位。

git bisect start
git bisect bad                  # 当前 HEAD 是坏的
git bisect good v2.3.0          # 这个 tag 是好的

Git 开始二分，每次检出一个中间提交，你测试后告诉它结果：

npm test                        # 跑测试或手动验证
git bisect bad                  # 这个提交也是坏的
# 或者
git bisect good                 # 这个提交是好的

重复几轮后，Git 会输出：

a1b2c3d is the first bad commit
commit a1b2c3d
Author: Zhang San <zhangsan@example.com>
Date:   Mon Oct 13 15:22:31 2026 +0800

    perf: 优化用户查询逻辑

定位完成后：

git bisect reset                # 回到原分支，清理 bisect 状态

自动化 bisect：让脚本来判断

如果有个测试能自动判定好坏，bisect 可以全自动跑完：

git bisect start HEAD v2.3.0
git bisect run npm test -- --grep "登录模块"

bisect run 对每个候提交执行命令：退出码 0 表示 good，非 0（1-127，除 125）表示 bad。注意 125 是保留码，表示"这个提交无法测试"（比如编译失败），bisect 会自动跳过。

实战技巧：先用 git log --oneline v2.3.0..HEAD -- src/ 缩小可疑文件范围，如果 bug 明显在某个模块，甚至可以先用 git bisect start HEAD v2.3.0 -- src/user/ 限定路径，减少每个候提交的干扰。

三个命令的选用决策

小结

cherry-pick 解决"提交搬家"，rebase -i 解决"历史整容"，bisect 解决"疑犯追责"。三者共同的思想是：把 Git 当成可检索、可裁剪的历史数据库，而不是只能追加的黑盒。下次遇到乱麻般的提交历史时，希望这三板斧能帮你干净收场。

你在工作中还用过哪些救命命令？欢迎评论区交流。