科技 · 实用指南
Git 提示 cherry-pick 为空？跳过前先检查暂存区
拟提交内容为空，不等于工作区干净，也不等于修复已交付。六个临时 Git 实验说明选择跳过、保留或丢弃前应检查什么。
空 cherry-pick 可能表示修改已存在、选中了刻意创建的空标记提交，或者冲突解决结果没有暂存差异。仅凭报错无法判断属于哪一种。
我们的 Git 2.51.1 实验也在所需修改仍未暂存时出现了这一提示。先区分拟提交内容与工作区，再决定跳过当前修改还是记录它。
同时读取操作状态与两种差异
运行 git status、git --version、git diff --cached 和 git diff。cached diff 比较拟提交内容与 HEAD；普通 diff 比较工作区与暂存区。还要检查未跟踪文件。cached diff 为空，不会让非空的普通 diff 消失。
确认 status 显示正在 cherry-pick 还是 rebase。rebase 会重放提交，内部也可能显示 cherry-pick 字样；使用实际操作对应的命令。不要删除序列状态文件，也不要用 reset --hard 压掉提示。
确认拟提交内容为什么为空
对普通单父提交，查看 git show COMMIT，并比较其修改、目标分支和你希望保留的解决结果。内容已存在，或把冲突完全解决为目标版本，都可能没有暂存差异；两者并不证明相同意图。合并提交需要有意识地选择主线父提交。
Tower 教程说明 cherry-pick 应用的是提交的差异，而非复制整个快照；其冲突流程也要求先暂存解决后的文件再继续。如果所需结果只在工作区，先审阅并暂存准确路径，再检查 cached diff。
根据当前状态选择策略
对已经停止的 cherry-pick，--skip 会跳过当前提交并继续后续序列。只有确认确实希望放弃该拟提交内容后才使用。若需要空的历史标记，先检查暂存区，按提示执行 git commit --allow-empty，再依 status 继续尚未完成的序列。
对新的执行，--empty=drop 处理后来变得冗余的修改；--empty=keep 保留它们，并隐含 --allow-empty。单用 --allow-empty 只保留原本为空的提交，并不接受所有冗余 pick。反过来，--empty=drop 本身也不接受原本为空的标记。旧版 Git 使用这些选项前，先查看本机帮助。
六个临时实验实际显示了什么
我们使用 Git 2.51.1、分别建立临时仓库，没有远程，也没有用户仓库。对已经应用的非空补丁，drop 成功且 HEAD 不动；keep 创建空提交；单用 --allow-empty 仍停止。对原本为空的提交，--empty=drop 也停止。这些结果验证了 Git 文档已经明确的区别。
双提交序列中，跳过冗余的第一项后，后续文件被应用，CHERRY_PICK_HEAD 清除。冲突实验中，我们先暂存目标版本，再留下所需但未暂存的修改；--continue 报告空 pick。--skip 成功，并保留该修改为未暂存工作，却没有把它交付为提交。这只是一个合成场景，不保证所有 skip 都保留任意本地修改。
核验交付，而非只看警告消失
执行所选动作后，再读 status、相关 log 与两种 diff。核对最终文件里的预期修复，运行有意义的验证，确认剩余序列完成。干净工作区、空标记和命令成功分别回答不同问题。不要仅因警告消失就推送。
当前手册与更新后的社区答案已经解释 keep/drop/stop；本文补充的是实际执行的双 diff 检查，揭示空提示下未暂存的解决结果。历史 Fork GUI 问题于 2022 年关闭，2026 年的复现评论未给版本；它只支持定性需求，不能证明所有当前 Fork 版本都有故障。
