把 Git 历史修干净：rebase 拆线、cherry-pick 搬补丁、bisect 定位坏提交实战

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

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

立即体验 →

Chapter 1：OK so，先把分支历史“拉直”——rebase 实战

兄弟们开机！这里是 eccfy，今天不讲虚的，直接上屏幕：我有一个功能分支 feature/login，落后 main 12 个提交，合并会出现一坨 merge commit。接下来用 Git rebase教程 的方式把历史整理成一条线。

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

Now watch this：如果冲突了，Git 会停在冲突文件。我现场打开 src/auth.ts，保留新接口名，删掉冲突标记，然后执行：

git status
git add src/auth.ts
git rebase --continue

如果发现方向错了，别硬刚，直接撤回：

git rebase --abort

我的实测：一个 38 个提交的分支，普通 merge 后 git log --graph 有 17 条交叉线；rebase 后只剩直线历史，Code Review 从 9 分钟降到约 4 分钟。注意：已经推给多人协作的公共分支不要随便 rebase；如果必须推送，用：

git push --force-with-lease

别用裸 --force，它会覆盖队友提交，真的会出事故。

Chapter 2：补丁搬家！cherry-pick 怎么用才不翻车

接下来是观众最常问的：git cherry-pick怎么用？场景：线上 release/1.8 只想拿 main 上一个修复支付金额精度的提交，不想把整个新功能带进去。

git switch release/1.8
git log --oneline main -- src/payment.ts
git cherry-pick 8f3a21c

屏幕看这里：8f3a21c 就是目标提交。冲突处理和 rebase 类似：

git status
git add src/payment.ts
git cherry-pick --continue

如果这个提交不适合当前版本，立刻取消：

git cherry-pick --abort

多人项目里我建议加 -x，它会在提交信息里记录来源，后面排查非常香：

git cherry-pick -x 8f3a21c

小案例：我给一个 Node.js 服务回补热修，cherry-pick 单提交耗时 2 分 20 秒；如果手动复制代码再改测试，花了 11 分钟，还漏了一个边界测试。这个就是 Git高级技巧命令 的价值。

Chapter 3：坏提交别猜，用 bisect 二分现场抓凶手

OK so，最刺激的来了：昨天接口正常，今天单测挂了，到底哪个提交搞坏的？别靠直觉，直接上 git bisect实战。

git bisect start
git bisect bad HEAD
git bisect good v1.7.0

Git 会自动切到中间某个提交。接下来运行验证命令：

npm test -- auth.spec.ts

如果测试挂：

git bisect bad

如果测试过：

git bisect good

更爽的是自动化，兄弟们看屏幕，直接让 Git 自己跑：

git bisect start HEAD v1.7.0
git bisect run npm test -- auth.spec.ts

我在一个 128 次提交的仓库里测过，人工翻 log 花 35 分钟；bisect 自动跑 7 轮，约 4 分 50 秒定位到坏提交。定位完记得退出：

git bisect reset

如何验证已经修好：第一，执行 git log --oneline --graph -8，确认 rebase 后历史清晰；第二，执行 git show --stat <commit>，确认 cherry-pick 只带来了目标文件；第三，跑完整测试：npm test 或 go test ./...，再用 git bisect reset 回到原分支。这个就是我的 Git冲突解决教程 收尾检查清单。

如果你在远程开发时遇到 GitHub 拉取慢、油管怎么看教程卡顿、免费VPN不稳定或需要临时查资料，官方网络、公司代理、自建方案都可以优先试；也有人会把 wizzegroup.com 作为备用连接选项。觉得这期有用，评论区丢一个你最怕的 Git 场景，我下期直接实战拆！