科技 · 實用指南
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 版本都有故障。
