遇到“conflict (content)”需手动解决：打开冲突文件，删除>标记及不需要的代码，保留正确逻辑；保存后执行git add 标记已解决，再运行git cherry-pick --continue继续操作。
Cherry-pick 时出现 “CONFLICT (content)” 怎么办
Git cherry-pick 遇到冲突，本质是它试图把某次提交的**补丁（patch）** 应用到当前分支，但目标文件已有改动，且 Git 无法自动判断哪部分该保留。这不是“合并失败”，而是补丁应用中断——你得手动裁决每处冲突后继续。
常见现象：error: could not apply abc1234... fix login timeout + CONFLICT (content): Merge conflict in src/api/auth.js，接着 Git 会停在冲突状态，不自动提交也不退出。
- 别直接
git add .或git commit—— 这会把冲突标记（, <code>====,>>>>）一起提交进去 - 先检查冲突文件：用编辑器打开
src/api/auth.js，定位到含和 <code>>>>> abc1234的段落 - 删掉冲突标记行，只保留你确认正确的代码逻辑（可能是 HEAD 版本、cherry-picked 版本，或两者融合）
- 保存后执行
git add src/api/auth.js标记已解决 - 再运行
git cherry-pick --continue让操作继续
为什么 resolve 后 git cherry-pick --continue 还报错
多数情况是漏掉了某个冲突文件，或者误删了 git add 步骤。Git 要求所有冲突文件都 git add 后才允许继续——它不检查内容是否真“解决”，只看 staging 是否干净。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
- 用
git status查看输出里是否还有unmerged paths，如果有，说明仍有文件未add -
git ls-files --unmerged可列出所有未合并项（比status更明确） - 如果中途想放弃，用
git cherry-pick --abort，它会还原到 cherry-pick 前状态，不会丢你本地修改 - 注意：不要用
git reset --hard强制回退，可能覆盖尚未add的解决结果
cherry-pick 多个提交时，一个冲突卡住，能跳过当前提交吗
可以，但要清楚后果：git cherry-pick --skip 会跳过当前冲突提交，继续处理后续提交——但被跳过的那个提交**不会出现在当前分支历史中**，也不会留下任何记录。
- 仅适用于你确认该提交不重要，或它依赖的上下文已不存在（比如原提交改了一个已被重写的配置文件）
- 跳过后仍可用
git cherry-pick <commit-hash></commit-hash>单独重试，或换用git show <commit-hash> | git apply -3</commit-hash>手动打补丁（更底层，需谨慎） - 若只是想“先绕过去，回头再理”，建议用
--abort中断，修复完再重新 cherry-pick，避免遗漏
cherry-pick 后发现 commit message 不对，能改吗
能，但分两种情况：刚完成（还没推） vs 已推送到远程。
- 如果刚
cherry-pick --continue完成，且没做其他提交，用git commit --amend修改 message 或 author；注意这会改变 commit hash - 如果已
git push，则不能 amend —— 否则需git push --force-with-lease覆盖，团队协作中需提前沟通 - cherry-pick 默认复用原提交的 author，但 committer 是你本人；如需保留原 author，加
-x参数（会自动追加(cherry picked from commit ...)），便于追溯
真正容易被忽略的是：cherry-pick 产生的提交和原提交内容相同，但 SHA-1 不同。这意味着即使你 cherry-pick 了别人修复 bug 的提交，CI/CD 系统或 code review 工具也不会自动识别这是“已审阅代码”，仍需走完整流程。
