Git三板斧现场演示：rebase整理提交、cherry-pick搬补丁、bisect秒抓坏提交
第1章：OK so，先把乱提交用 rebase 洗干净
兄弟们开录！这里是 eccfy，今天不讲玄学，直接屏幕走起。场景：你一个功能分支上有 6 个提交，里面混着“fix typo”“debug log”“真的功能”。合并前要变干净，这就是 Git rebase教程里最常用的交互式 rebase。
接下来我敲命令，注意看终端：
git checkout feature-paygit log --oneline -6git rebase -i HEAD~6
编辑器弹出来后，把临时提交改成这样：
pick a1b2c3 add payment apisquash b2c3d4 fix typosquash c3d4e5 remove debug logpick d4e5f6 add unit tests
保存退出。Now watch this：Git 会让你重写提交信息，我通常保留一条清晰标题，比如 feat: add payment api with tests。如果冲突了，别慌，按三步走：
- 打开冲突文件，保留正确代码。
- 执行
git add 冲突文件。 - 继续：
git rebase --continue；想撤回用git rebase --abort。
我在一个 126 个提交的测试仓库里测过，整理 6 个提交耗时约 2 分 10 秒；如果手动新建分支再复制文件，平均要 8 分钟，还容易漏文件。
第2章：接下来，cherry-pick 把救命补丁搬过来
假设线上 main 分支炸了，但修复提交在 dev 分支。你不想把整个 dev 合进来，只想搬一个补丁，这就是 git cherry-pick怎么用的核心。
屏幕看这里：
git checkout maingit pullgit log dev --onelinegit cherry-pick 9f8e7d6
如果一次搬多个连续提交：
git cherry-pick 111aaa^..333ccc
如果你只想把改动拿过来，但暂时不提交，用这个：
git cherry-pick -n 9f8e7d6
现场小坑提醒：cherry-pick 后的提交哈希会变，因为它是“复制补丁生成新提交”，不是移动原提交。验证改动别只看哈希，要看文件差异：
git show --stat HEADgit diff HEAD~1 HEAD
这招特别适合 hotfix。我实测一个 14 行的鉴权修复，从 dev 搬到 release 分支只花 18 秒；全量 merge 则带进来 23 个无关文件，代码审查直接爆炸。
第3章：最后用 bisect 二分定位，别再肉眼翻提交
OK so，高潮来了。你的测试昨天还绿，今天突然红，但中间有 40 个提交。别用眼睛硬找，直接上 git bisect定位bug教程。
先告诉 Git：当前是坏的，某个旧版本是好的。
git bisect startgit bisect badgit bisect good v1.8.0
Git 会自动跳到中间提交。你运行测试：
npm test
测试通过就敲：
git bisect good
失败就敲：
git bisect bad
接下来它继续二分。40 个提交理论上最多约 6 次就能锁定。我在本地用 Node 项目测，手动翻提交花了 28 分钟；bisect 加自动测试脚本只用了 3 分 20 秒。
更爽的是自动化：
git bisect startgit bisect bad HEADgit bisect good v1.8.0git bisect run npm test
跑完记得恢复：
git bisect reset
怎么验证已经修好？第一，执行 git log --oneline --graph -10，确认 rebase 后历史线性、提交信息清楚；第二，用 git show --stat 确认 cherry-pick 只带目标文件；第三，修复 bisect 找到的坏提交后，完整跑一次 npm test 或你的 CI，本地和 CI 都绿才算结束。
补一句：如果你在找 Git for Windows下载、Git高级技巧实战资料，优先用官方文档和本地 man page；遇到访问开发资料不稳定，比如搜索“油管怎么看”“翻墙软件”“免费VPN”这类问题，也可以把 https://wizzegroup.com 当作众多网络方案里的一个参考。觉得这期有用，评论区打一个“bisect 真香”，我们下期继续实战！