昨天我在我的主分支中挑选了两个提交，其中一个导致了合并冲突，我解决了它们，提交并将它们推送到原点。今天，当我收到以下错误时，我试图从服务器中提取：
$ git pull
fatal: You have not concluded your cherry-pick (CHERRY_PICK_HEAD exists).
Please, commit your changes before you can merge.
$
Git状态读取：
$ git status
# On branch main
# Your branch is behind 'origin/main' by 2 commits, and can be fast-forwarded.
#
$
我尝试了以下方法无济于事：
$ git cherry-pick --continue
usage: git cherry-pick [options] <commit-ish>
$
关于如何解决这个问题的任何想法？提前致谢！
下次试试git cherry-pick --abort，否则你所做的应该或多或少的工作。
解决了以下问题：rm .git/CHERRY_PICK_HEAD我意识到这很危险，因为这不能保证 git 内部的一致性，但到目前为止对我来说没有问题......
自从我之前的回答 2014以来，现在（2018 年）正确的命令是git cherry-pick --quit.
在 Git 2.19（2018 年第 3 季度）之前，" git cherry-pick --quit" 无法删除CHERRY_PICK_HEAD，即使我们不会在它返回后进行挑选会话，这已得到纠正。
请参阅Nguyễn Thái Ngọc Duy ( ) 的提交 3e7dd99（2018 年 8 月 16 日）。（由Junio C Hamano 合并——在提交 39e415c中，2018 年 8 月 20 日）pclouds
gitster
cherry-pick：修复 --quit 不删除 CHERRY_PICK_HEAD
--quit应该是--abort但没有恢复HEAD。
留下CHERRY_PICK_HEAD可能会导致其他cherry-pick仍在进行的命令错误（例如“git commit --amend”将拒绝工作）。也清洗一下。因为
--abort，这个删除工作CHERRY_PICK_HEAD在“git reset”上，所以我们不需要做任何其他事情。但是让我们在测试中添加额外的检查--abort来确认。
如果git cherry-pick --continue不起作用，则意味着 git 太旧：在提交 5a5d80f中为 git 1.7.8（2011 年 12 月）引入了该选项
它的工作原理是从 .git/sequencer/todo 中删除第一条指令并执行那里列出的剩余的樱桃选择，并使用“ ”中列出的初始命令中的选项（想想“
-s”和“ ”） 。-X.git/sequencer/opts
这些天（2014 年），这将是您看到“ You have not concluded your cherry-pick”时使用的命令。
另一种选择：使用 Git 2.23（2019 年第三季度），agit cherry-pick --continue将真正起作用！
当多步cherry-pick 或revert 中的一个步骤被reset 或commit 时，命令行提示脚本未能注意到当前状态，已改进。
请参阅Phillip Wood ( ) 的commit e981bf7（2019 年 7 月 1 日）。（由Junio C Hamano 合并 -- --在8a4acc5 提交中，2019 年 7 月 19 日）phillipwood
gitster
git-prompt：改善cherry-pick/revert检测如果用户在一系列选择或恢复的过程中提交或重置冲突解决方案，则
CHERRY_PICK_HEAD/REVERT_HEAD将被删除，因此在没有这些文件的情况下，我们需要检查.git/sequencer/todo是否存在选择或恢复进步。查看是否
cherry-pick正在进行revert中，如果用户git commit在一系列选择或恢复过程中使用 ' ' 提交了冲突解决方案，则CHERRY_PICK_HEAD/REVERT_HEAD将不存在，因此我们必须读取todo文件。