你执行 git cherry-pick abc1234 把一个修复回合到目标分支，在 src/auth.ts 里解决了冲突，用 git add 暂存后执行 git cherry-pick --continue，结果 Git 停下来报：
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:
git commit --allow-empty
Otherwise, please use 'git cherry-pick --skip'这不是 bug，你的解冲突大概率也没错。绝大多数情况下，它的意思是：你要移植的改动在目标分支上已经存在了，三路合并之后净 diff 为零，所以没有内容可提交。
最快修复： 如果这个改动确实已经在当前分支上，直接 git cherry-pick --skip 跳过就行。只有当你确实想保留一个空 commit（审计记录、或想维持 SHA 一一对应）时才用 git commit --allow-empty。先按 Step 1 跑两条 diff 检查，确认不是误判，再决定跳过。
10 秒选对处理方式
先跑这两条命令，再对照下表里匹配的那一行：
git diff HEAD | git diff --cached | 含义 | 怎么做 |
|---|---|---|---|
| 空 | 空 | 真空 commit，改动已在目标分支 | git cherry-pick --skip |
| 空 | 空 | 是空的，但你想留个记录 | git commit --allow-empty -m "..." 再 git cherry-pick --continue --no-edit |
| 有输出 | 空 | 你忘了把解冲突结果 git add | git add <file> 再 git cherry-pick --continue --no-edit |
| 任意 | 任意，但内容不对 | 你解冲突时选错了一侧 | git cherry-pick --abort 重做（见原因 2） |
git diff HEAD 比较工作区与上一个 commit，git diff --cached 比较暂存区与上一个 commit。两者都为空，说明工作区、暂存区、HEAD 三者完全一致，没有任何内容可提交。
常见原因
按命中率从高到低排列。
1. 目标分支已经包含等效改动
你要 cherry-pick 的 commit 改的那些行，目标分支上已经被改过了——可能是之前的另一次 cherry-pick、一次 merge，或者一个并行修复。三路合并后解出来的内容和现状一致，diff 为空。
怎么判断： 暂存后 git diff HEAD 为空，说明工作区已经和 HEAD 一样。再用 git branch --contains abc1234 确认：如果目标分支在列表里，说明这个 commit（按 SHA）已经在它的历史中了。
2. 解冲突时全部选了「ours」
解冲突时你对每个冲突块都执行了 git checkout --ours -- src/auth.ts（或在合并工具里点了「用当前/HEAD」）。在 cherry-pick 语义下，--ours 是你要移植到的分支（你的 HEAD），--theirs 是你要移植进来的那个 commit。全选 ours 等于保留目标分支原样，把要移植的改动全丢了，于是成了空 commit。
怎么判断： 即使暂存了文件，git diff --cached 也没有任何改动。如果你其实是想要那个 incoming 改动的，这是唯一一种不该跳过的情况——应当 abort 后改用 --theirs 重做。
3. cherry-pick 的是 merge commit，但没加 -m
git cherry-pick <merge-sha> 没有默认的 parent 作为 diff 基准，会失败、产生空 commit，或得到一个错乱的结果。
怎么判断： git show --stat <sha> 会打印一行 Merge: abc1234 def5678。改用指定主线 parent 重新 pick：git cherry-pick -m 1 <merge-sha>（parent 1 通常是这个 merge 落到的那条分支，parent 2 是被合并进来的分支）。
4. cherry-pick 一个「revert 的 revert」（双重否定）
你要 pick 的 commit B 是对 commit A 的 revert，而目标分支也通过另一条路径 revert 了 commit A。两次 revert 得到相同内容，所以没什么可做。
怎么判断： git show abc1234 --stat 显示这是个 revert，再用 git log --oneline --grep="Revert" 看目标分支历史里是否已有等效的 revert。
5. 纯空白差异被解成了零
源 commit 只改了行尾空格或缩进，而目标分支已经跑过一次自动格式化，于是实际 diff 为空。
怎么判断： git diff --ignore-all-space HEAD 也为空，说明被 pick 的 commit 本身就没有语义上的改动。
6. 批量 pick 范围里有些 commit 已经应用过
git cherry-pick A..B 会 pick 多个 commit，其中某个中间的 commit 之前已经被单独回合过，于是在处理到它时变成空的。
怎么判断： git log --oneline A..B 列出比如 5 个 commit，但 git log --oneline target..HEAD 显示其中 3 个已经在了。只有这种情况下 --empty 参数才帮得上忙（见 Step 5）。
最短修复路径
Step 1：确认是真空 commit 还是误操作
git diff --cached
git diff HEAD两者都为空，说明 cherry-pick 确实是空的。如果 git diff HEAD 有输出而 git diff --cached 为空，说明你忘了暂存解冲突结果——去 Step 2。
Step 2：先暂存还没 add 的解冲突文件
git add src/auth.ts
git cherry-pick --continue --no-edit--no-edit 会复用原始 commit message，不弹编辑器。
Step 3：确实是空的，选择跳过还是允许空提交
方案 A——跳过（改动已在目标分支时推荐）：
git cherry-pick --skip方案 B——保留一个空 commit（用于审计记录，或维持 SHA 一一对应）：
git commit --allow-empty -m "chore: cherry-pick abc1234 (no-op on this branch, change already present)"
git cherry-pick --continue --no-edit这里不要用 git cherry-pick --continue --allow-empty 去硬推：因为由解冲突产生的空 commit，Git 会按「一开始就为空」来对待，只有 --skip、git commit --allow-empty 或 --empty=keep 才能让它继续，--empty=drop / --empty=stop 对它无效（见 Step 5）。
Step 4：如果是选错了一侧（原因 2），重做
git cherry-pick --abort
git cherry-pick abc1234
# 遇到冲突时，保留 INCOMING 改动：
git checkout --theirs -- src/auth.ts
git add src/auth.ts
git cherry-pick --continue --no-editStep 5：批量 pick 时自动丢弃冗余的 commit
对 git cherry-pick A..B，因为同一范围内前面的 commit 已经应用过而变空的 commit，可以自动丢弃：
git cherry-pick --empty=drop A..B重要限制（已对照官方文档核对，截至 2026 年 6 月）：--empty=drop 和 --empty=stop 只管理因为范围内前一个 commit 而变空的 commit。由解冲突变空的 commit（也就是你现在的情况）会被当作「一开始就为空」，依然会让 pick 停下——这种情况要逐个用 --skip，或者用 --empty=keep / --allow-empty 来保留它。--keep-redundant-commits 是 --empty=keep 的已废弃同义参数。
Step 6：验证最终结果
git status # 应显示 "nothing to commit, working tree clean"
git log --oneline -5
git diff origin/target-branch -- src/auth.tsgit status 应当显示没有正在进行的 cherry-pick，且目标修复确实已在分支上。
预防建议
- pick 前先查这个 commit 是否已经在了：
git branch --contains abc1234。目标分支在列表里，pick 就会是空的。 - 用
git cherry -v target source列出尚未等效应用的 commit——开头是-表示该 patch 已应用（pick 会空），+表示是新的。 - 批量 pick 前先看清楚：
git log --oneline A..B与git log --oneline target交叉对照。 - 对 merge commit 做 pick 时始终带上
-m 1，并在 PR 描述里注明。 - 自动化 pick 脚本里，范围操作优先用
--empty=drop，单个冲突场景用--skip，并把跳过的 SHA 记进日志，让团队知道哪些是 no-op。 - 用一个
BACKPORTS.md文件或 PR 标签追踪哪些 commit 已经回合到哪些分支，避免队友重复劳动。
常见问答 (FAQ)
Q：为什么 --empty=drop 不跳过我这个解冲突变空的 commit？
A：这是设计如此。Git 文档写明 --empty=drop / --empty=stop 只处理因为前一个 commit 而变空的情况。由解冲突变空的 commit 会被当作一开始就为空，依然会让 pick 停下——请用 git cherry-pick --skip（或用 --empty=keep / --allow-empty 保留它）。
Q：我执行了 --skip，但目标分支上没有那个修复，怎么回事？
A：跳过意味着 Git 判断这个改动在当前分支上已等效存在。用 git log --all --oneline --grep="修复关键词" 或 git log --all --oneline -- src/auth.ts 找它落在了哪里——可能是另一个 commit message，或在另一条分支上。
Q：能只 cherry-pick 一个 commit 里的某一块改动吗？
A：可以。先 git cherry-pick -n abc1234（-n / --no-commit 只暂存不提交），再 git restore --staged <不要的文件> 取消暂存不想要的文件，最后 git commit。
Q：git cherry-pick --continue 报 “no cherry-pick in progress”，哪里出问题了？
A：这次 cherry-pick 序列已经结束了。看 git status——如果工作区干净、git log -1 显示的是你 pick 的 commit，就说明已经完成。用过 --skip 或 --abort 也会清掉「进行中」状态。
Q：空 commit 已经推送了，怎么删掉？
A：如果这条分支可以安全改写历史，用 git rebase -i HEAD~5 删掉那一行（若它在最顶端则用 git reset --hard HEAD~1），然后 --force-with-lease 强推。如果是受保护的共享分支，就别动了——一个空 commit 是无害的。
Q：我们经常往 release 分支 cherry-pick 热修复，有没有更好的流程？
A：可以考虑「fix-forward」：热修复先落到 release 分支，再 merge 回 main。diff 方向永远向前，能避开大多数 cherry-pick 变空的情况。
相关阅读
- Rebase 之后 commit 消失了
- 我在 detached HEAD 状态下提交了，怎么办？
- git pull —rebase 打乱了我的冲突解决历史
- Revert merge commit 提示需要 -m parent
- 二进制文件合并冲突 — 手动无法 resolve
- AI 帮你解决合并冲突
- git Find Old Version
标签: #git #version-control #排查