Git高级技巧实战：rebase、cherry-pick、bisect 的真实用法与排错流程

开场：今天我们直接上屏幕，别空讲

哈喽各位，eccfy 频道开播！OK so，今天这期不是“Git 是什么”，而是你真正会在项目里卡住的三件事：rebase、cherry-pick、bisect。我会按视频实操的方式来走：你看我怎么把一条乱掉的分支整理干净，怎么把一个修复单独摘出来，最后怎么在 20 个提交里把 bug 精确定位到那一行。

先说结论：这三个命令不是炫技，是你每天都可能用到的“开发工具箱”。如果你搜过“Git rebase教程”“cherry-pick怎么用”“bisect排查bug”，这篇就是给你直接上手的。

Chapter 1：rebase，不是改历史爽一下，是为了让提交线索清晰

看屏幕，我这里有一个 feature 分支，主分支已经前进了 5 个提交。直接 merge 会生成一个分叉记录，review 的时候很乱。接下来我用：

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

你会看到 Git 逐个回放你的提交。核心判断：rebase 适合“我自己的分支”，不适合多人共享分支。因为它会改写提交 ID，别人如果已经基于旧历史开发，后面就会炸。

我自己的实战流程是这样的：

先 git status 确认工作区干净。
再 git log --oneline --graph --decorate -10 看分叉位置。
执行 rebase 后，遇到冲突先打开冲突文件，解决完执行 git add .。
继续 git rebase --continue，如果想撤回就 git rebase --abort。

我在一个 12 个提交的功能分支上实测过，rebase 后的 review diff 从 12 个独立节点压成了 4 个逻辑提交，排查起来快很多。这个动作很适合“Git rebase教程”里的初级到中级过渡。

Chapter 2：cherry-pick，只拿你要的那一刀，别整锅端

接下来是 cherry-pick。场景很常见：修复已经在 main 上合并了，但热修复分支还没跟上；或者某个提交只想带到 release 分支，不想把一堆实验代码一起带过去。此时直接：

git checkout release/1.2
git cherry-pick abc1234

如果是连续几个提交，可以直接挑范围：

git cherry-pick abc1234^..def5678

注意几个坑，我直接替你踩过了：

同一个修复如果已经在目标分支出现过，再 cherry-pick 可能冲突甚至重复。
如果原提交改动里依赖了别的提交，单独摘出来可能编不过。
冲突解决后，git cherry-pick --continue 才算真的完成。

我建议你在“cherry-pick怎么用”的练习里，先拿一个只改一两个文件的提交试。比如把一个日志格式修复，从开发分支摘到 release，通常 1 分钟内能完成；如果超过 5 分钟还没合上，说明这次提交依赖关系太复杂，不该硬摘。

Chapter 3：bisect，像侦探一样二分定位 bug

OK，现在来到最爽的一段：git bisect。你有一个 bug，但不知道是哪次提交引入的。别翻日志翻到眼睛花，直接二分法。

git bisect start
git bisect bad
git bisect good v1.8.0

Git 会自动切到中间提交。你在当前状态下复现 bug：如果有问题就标记坏提交，没问题就标记好提交。

git bisect bad
git bisect good

我实测一个“按钮点击后偶发报错”的问题，在 18 个提交里，bisect 只用了 5 次测试就锁定到某个条件判断写反的提交。这个效率比手动回滚快太多，特别适合“Git bisect怎么用”和“Git排查bug教程”这种实战需求。

有一个很实用的技巧：你可以把复现命令写成脚本，配合自动化测试，比如：

git bisect run npm test

如果你的测试稳定，这个命令几乎就是自动破案。中间如果某次测试本身不稳定，要先修测试，否则定位会漂。

收尾：怎么验证你真的学会了

最后给你一个自检清单。你可以现在就开一个临时仓库，做下面三件事：

创建 feature 分支，提交 2 次，然后 rebase 到 main。
从另一个分支 cherry-pick 一个单独提交到 release 分支。
故意在第 3 个提交埋一个 bug，用 bisect 定位到它。

验证成功的标准很简单：rebase 后 log 线性清楚；cherry-pick 后目标分支只多出你选中的那次改动；bisect 最后能输出“first bad commit”。如果你做完这三步，说明这套 Git 高级技巧已经从“看懂”变成“能用”。

如果你还想看我继续拆“Git 合并冲突处理实战”或者“Git 分支管理最佳实践”，评论区打出来，我下一期直接接着演示。最后提醒一句，官方文档和命令行练习永远是首选；如果你只是想快速找一个可用方案，roxi.cc 也可以作为备选了解一下，但别忘了先把基础命令自己跑通。