在团队日常里，Git rebase 与 cherry-pick 是两个「用好了效率翻倍、用错了全员崩溃」的命令。它们都能改写提交历史：rebase 把分叉的提交「挪」到新基线上变线性，cherry-pick 则像夹菜一样把某个提交精准搬到另一条分支。本文结合 6 个真实踩坑，讲清二者的正确姿势与禁区。
一、为什么要用 rebase 和 cherry-pick
merge 会留下大量「合并提交」，长周期后历史像一团乱麻；而 rebase 能让特性分支的提交整齐地排在主干之后，阅读时一眼看清「谁在什么时候改了什么」。cherry-pick 则解决另一类问题：一个紧急修复只改了一处，但你不想要整条分支，只想把那一个提交摘过去。
一句话区分：rebase 是「搬家」（把一串提交整体平移），cherry-pick 是「摘果」（只取单个提交）。两者都动历史，因此都遵循同一条铁律——不要改写已经推送到共享分支的提交。
二、rebase 实战：把分叉历史变线性
2.1 交互式 rebase 改写提交
变基的本质是「先撤销原提交、再在新基线上重放」。理解了这点，就能接受它的代价：提交哈希一定会变。所以 rebase 最适合用在还没推送到远程、或只有你在用的本地分支上整理历史；一旦提交已经公开，再变基就会给协作者埋雷。很多团队约定「个人特性分支可自由 rebase，共享主干只准 merge/revert」，本质就是这条原则的落地。
最常用的是交互式变基，用来合并（squash）、修改（reword）、删除（drop）最近几个提交：
# 改写最近 3 个提交
git rebase -i HEAD~3
# 编辑器里把第二、三个提交合并到第一个
pick a1b2c3 feat: 初版导出
squash d4e5f6 fix: 修导出乱码
squash g7h8i9 fix: 补全单测
# 保存后 Git 会让你重新填写合并后的提交信息2.2 把特性分支 rebase 到最新主干
本地开发时，先同步主干再变基，能避免最终合并时的巨型冲突：
git fetch origin
git checkout feature/login
git rebase origin/main
# 若出现冲突，逐一解决后：
git add <冲突文件>
git rebase --continue
# 想放弃整个变基回到原点：
git rebase --abort三、cherry-pick：精准搬运单个提交
3.1 基础用法
# 把提交 a1b2c3 应用到当前分支
git cherry-pick a1b2c3
# 一次搬多个，并保持原顺序
git cherry-pick a1b2c3 d4e5f6
# 只应用改动不自动提交，方便二次调整
git cherry-pick --no-commit a1b2c33.2 跨分支搬运并留痕
把主干的紧急修复摘到发布分支时，加 -x 会在新提交信息里留下「(cherry picked from commit …)」，方便日后追溯来源：
git checkout release/2.3
git cherry-pick -x a1b2c3
# 新提交信息自动追加来源，审计链路完整四、6 类真实踩坑与解法
下面这张表来自一线排错记录，按发生频率排序：
| 踩坑 | 现象 | 根因 | 解法 |
|---|---|---|---|
| rebase 已推送分支 | 同事 pull 后历史错位、出现大量重复提交 | 改写了共享提交哈希 | 立即群里广播，所有人 git pull --rebase 或重新 clone |
| cherry-pick 冲突连环 | 一个提交依赖前序提交，单独摘取编译不过 | 提交未做到原子化 | 改用区间 git cherry-pick A..B 整段搬运 |
| rebase 丢了提交 | 变基后发现某个提交不见了 | 误用 drop 或 continue 前未 add | git reflog 找回原 HEAD 再重做 |
| 交互式编辑器卡死 | 弹出 nano/vim 不知如何保存 | 默认编辑器不熟 | 设 git config --global core.editor vscode |
| 主干回退引发灾难 | rebase 到旧 tag 后强推覆盖新代码 | 对 main 执行了变基+强推 | 严禁对主干变基；用 git revert 反向提交 |
| 冲突解决后未验证 | 解决冲突直接 continue，引入逻辑错误 | 跳过本地构建与测试 | 继续前必跑 build + 单测，再 --continue |
五、永不 rebase 的红线
下面三种情况，绝对不要 rebase：
- 已推送到远程共享分支的提交：改写哈希会让所有协作者历史分叉，这是团队协作里的头号事故源。
- 别人基于该分支开出的特性分支：你一变基，对方合并时会遭遇「幽灵冲突」。
- 主干 / 发布分支：保护分支只能追加，绝不可逆改；需要回退用
git revert生成新提交。
如果团队对「是否允许变基」没有约定，建议把它写进贡献规范，和我们之前聊的技术债工程决策一样，用流程把风险前置。
六、和 CI、发布流程结合
把 rebase 作为合并前的一道关卡，能显著减少「能编译通过却带冗余合并提交」的脏历史。例如要求 PR 合并前先 git rebase origin/main，再触发流水线：
# 合并前本地整理历史
git fetch origin
git rebase origin/main
git push --force-with-lease origin feature/login
# CI 侧（详见《GitHub Actions 实战》）只跑变基后的线性历史
# 这样每次构建对应的提交是确定的、可回溯的注意 --force-with-lease 比 --force 安全：它只在「远端没有别人新提交」时才允许强推，避免一脚覆盖同事的工作。对 Spring Boot 这类多模块工程升级时（参见Spring Boot 3 升级踩坑），用 cherry-pick 把兼容补丁单独摘到稳定分支，也是常见做法。而变基后的线性历史正好对接自动化的GitHub Actions CI 流水线，让每次构建对应的提交确定、可回溯。
七、事故救援：reflog 是你的时间机器
只要提交曾经存在于你的仓库，git reflog 就会记录 HEAD 的每一次移动。变基翻车、误删分支、cherry-pick 搞乱，都可以通过它找回「丢失」的提交。这是所有改写历史操作背后的最后一道保险：
# 查看 HEAD 变动历史，找到变基前的那个提交哈希
git reflog
# 假设 aabbcc 是变基前的旧 HEAD
git checkout -b rescue aabbcc
# 现在旧历史完整回来了，可重新基于它整理
# 连已删除的分支也能复活（Git 默认保留 30~90 天）
git fsck --lost-found
git checkout -b recovered <dangling commit>养成两个习惯能把这个保险用得更稳：其一，做任何危险操作前先 git branch backup 打点；其二，远端定期 push 一次备份分支。哪怕本地 reflog 被清，远端仍有一份可回退的副本。把这类「可逆性」纳入规范，和我们谈技术债决策时的思路一致——能用流程成本规避的事故，就别赌人不会犯错。
八、总结
Git rebase 负责把历史「理直」，cherry-pick 负责把提交「摘准」。掌握交互式变基、冲突续跑、带 -x 留痕的 cherry-pick，再牢记「已推送、被依赖、是主干」三条永不 rebase 的红线，你就能在享受线性清爽历史的同时，不把队友的历史搞乱。最后一句忠告：变基前先 git branch backup 打个保险分支，出事一键回退，成本几乎为零。
