Git cherry-pick 冲突处理：继续、跳过和中止分别改变什么
维护旧版本时，常要把另一条分支的一次修复带回来。cherry-pick 重放的是所选提交引入的改动，不会自动合入那条分支的全部历史。相同补丁放到不同上下文中可能冲突，也可能无冲突却语义错误。本文以 Git 2.50 手册为依据，示例适用于 Git 2.50 及以上的普通非合并提交，使用 Bash；先在全新临时仓库练习。
AI生成概念配图：把一个分支的改动移入另一条提交链，并在连接处处理差异。仅作概念说明，不代表实际界面或实测结果。
先确认目标和干净现场
真实项目里先运行 git status，确认当前分支就是接收修复的分支，并处理好已有未提交内容。再用 git show 查看源提交修改了什么、依赖了哪些前置改动。只复制一个提交编号，不代表它能独立运行；如果同时依赖数据库结构或配置更新，应先制定完整迁移方案。不要为图省事直接把整个提交区间一起应用。
work=$(mktemp -d) cd "$work" git init -b main git config user.name 'Tutorial' git config user.email 'tutorial@example.invalid' printf 'mode=base\n' > app.conf git add app.conf git commit -m 'base' git switch -c feature printf 'mode=feature\n' > app.conf git commit -am 'feature setting' source_commit=$(git rev-parse HEAD) git switch main printf 'mode=main\n' > app.conf git commit -am 'main setting' git cherry-pick "$source_commit"
最后一条预期报冲突并以非零状态退出，因为两边修改了同一行。这是演练的一部分，不要放进遇错立即退出却没有观察步骤的流水线。上述身份设置只写入临时仓库，目录路径由系统生成；不要把初始化及写文件命令改在现有工作目录中运行。
冲突时先读状态，再决定要不要继续
git status --short git diff --name-only --diff-filter=U git diff -- app.conf git show CHERRY_PICK_HEAD -- app.conf
此时 HEAD 仍停在当前分支最近成功提交处，冲突文件会有未合并状态。CHERRY_PICK_HEAD 指向正在应用的源提交，能帮助区分“原补丁想做什么”和“目标分支现在是什么”。不要只删除冲突标记就算解决，更不要机械地全部保留某一侧；应根据目标版本的功能意图合成最终内容。
如果发现选错提交，先在这一刻演练中止，然后重新应用同一提交。以下两条是同一个 Bash 会话中的操作，中止会放弃本次冲突处理产生的变化，回到序列开始前。重要的人工尝试若仍需保留，应先另行记录。
git cherry-pick --abort git cherry-pick "$source_commit"
暂存的是你审查过的结果
printf 'mode=combined\n' > app.conf git add app.conf git diff --cached --check git diff --cached git -c core.editor=true cherry-pick --continue git show --stat --oneline HEAD
combined 只是本演练约定的最终值，真实配置必须符合应用支持的语法和含义。git add 标记该路径已解决，暂存差异才是将要提交的内容；--check 可发现部分空白问题和冲突标记，却不会替代业务测试。继续前至少运行相关单元测试，继续后再次确认提交范围，避免把额外文件一并带入。
不要混淆四个出口
--continue 继续尚未完成的序列；--skip 放弃当前源提交，接着处理后面的提交；--abort 取消整个本次序列并回到开始状态；--quit 只忘记进行中的操作状态，不承诺把工作区恢复原样。处理多个提交时，中止的范围尤其值得确认。补丁变空也应先判断是否已包含相同修复，再决定是否跳过。
本文不演示合并提交的 -m 主线选择，也不涉及重写已推送历史。完成移植后应保留来源说明、目标版本测试结果和审查记录。没有冲突只是文本应用成功，只有这些检查完成，才能判断修复是否真的适合目标分支。
