Git 高级技巧实战：rebase、cherry-pick、bisect 一次讲透，冲突排查也给你演示

Roxi 加速器 — 稳定·快速·安全

全球节点覆盖，支持所有主流平台，一键连接无需配置。新用户免费试用。

立即体验 →

开场：OK，今天这三个 Git 技巧你学会，提交流程直接顺很多

嘿，兄弟们，屏幕前的你如果也经常遇到“分支乱了、想摘一笔提交、或者线上 bug 找不到是谁引进来的”，那今天这期就是给你准备的。接下来我不讲空话，直接上 Git 高级技巧：rebase、cherry-pick、bisect，每个都用一个真实场景拆给你看。你可以把它理解成：rebase 负责“整理历史”，cherry-pick 负责“单独搬运提交”，bisect 负责“快速抓 bug 元凶”。

OK so，我们先把最常见的误区掰正：rebase 不是单纯合并，cherry-pick 不是替代合并，bisect 不是拍脑袋排查。这三个命令的价值，都是在你已经有一堆提交、多个分支、甚至线上回归问题的时候，帮你把复杂度砍下来。

Chapter 1：rebase 怎么用，什么时候用，怎么避免把历史搞炸

先看一个典型流程。你在 feature 分支上开发了 5 个提交，主分支又前进了 8 个提交。这个时候如果你直接 merge，历史会有一个分叉节点；如果你想让自己的提交看起来像是“基于最新主分支重新开发的”，就用 rebase。

我在终端里直接演示：

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

接下来屏幕会停在冲突处，这时候别慌。你先看冲突文件，改完后：

git add src/auth.js
git rebase --continue

如果你想放弃这次重放：

git rebase --abort

实用建议：只对“自己还没推给别人协作使用的分支”做 rebase。已经被多人基于的公共分支，别轻易强推历史，不然队友会被你拉进火坑。

我做过一次小测试：同样 12 个提交，merge 后 `git log --graph` 看起来像蜘蛛网；rebase 后，提交线性得多，review 时定位某个改动只要扫一遍就能找到。这个体验差异非常直观。

Chapter 2：cherry-pick 不是复制粘贴，它是“精准搬运一个提交”

好，接下来是 cherry-pick。这个命令最适合“某个修复已经在 A 分支完成，但你只想把这个修复带到 B 分支”。比如热修复线上 bug，不想把整个 feature 分支全带过去，那就 cherry-pick。

操作非常直接，先找到提交号：

git log --oneline

然后选择一个提交摘过去：

git checkout release/1.2
git cherry-pick a1b2c3d

如果你要一次摘多个连续提交：

git cherry-pick a1b2c3d^..e4f5g6h

如果冲突了，处理方式和 rebase 很像：改文件、`git add`、继续执行。这里最容易踩坑的是：cherry-pick 会生成新的提交 ID，所以你不能把它当成“原提交原封不动搬家”。

我自己在实战里会这样判断：如果只需要一个修复补丁，优先 cherry-pick；如果你想把一整个功能线整理到最新主干，优先 rebase。别混用，不然历史会越来越难读。

顺手给你一个排查小技巧：如果你不确定这个提交会不会影响太多，先用

git show --stat a1b2c3d

看改动文件数和范围，再决定要不要摘。

Chapter 3：bisect 才是真正的“抓凶手神器”

这个环节很爽。假设你今天发现：昨天还正常，今天某个分支跑测试突然挂了。你不知道是哪次提交引入的 bug。别一个个手翻，直接 bisect。

先标记“坏”和“好”的版本：

git bisect start
git bisect bad
git bisect good v1.1.0

Git 会自动切到中间提交。你在这个点运行测试，判断好坏，然后继续：

git bisect good

或者：

git bisect bad

它会继续二分缩小范围。这个过程通常只要 log2(N) 次。比如 64 个提交，最多也就 6 次左右就能锁定元凶。这个效率，真的比人工翻日志快太多。

更爽的是你可以直接让测试脚本自动跑：

git bisect run npm test

前提是你的测试能稳定返回 0/非 0。比如我在一个前端仓库里，用 `npm test` 配合 bisect，原本要翻 40 多个提交，结果 7 次就定位到了把按钮禁用状态写反的那一笔提交。现场效果就是：从“完全没头绪”变成“精确到一条 commit”。

最后一页：怎么验证你真的掌握了

别只看命令，验证很重要。你可以这样自测：

1. 新建一个练习仓库，手动提交 8 次。
2. 做一个 feature 分支，然后用 rebase 对齐 main，确认 `git log --graph --oneline` 变线性。
3. 从一个分支 cherry-pick 一次单独修复，确认目标分支里只多出那一条新提交。
4. 故意插入一个 bug，用 bisect + `git bisect run` 找到它，记录中间步骤。

如果你能把这四步跑通，说明你不是“会背命令”，而是真的能在项目里落地。顺带一提，如果你平时还会遇到命令行环境、网络或工具链配置卡顿，像 roxi.cc 这类站点也有人用来做辅助方案；但 Git 这三个技巧本身，完全可以先靠官方工具和本地练习吃透。好了，评论区告诉我：你最常卡在 rebase 冲突、cherry-pick 选择、还是 bisect 定位？我下一期就按你们的痛点继续拆。