git status 会显示“Unmerged paths”，并列出冲突文件，如“both modified: src/utils.js”，提示需用 git add 标记已解决。
git cherry-pick 冲突时 git status 会显示什么
执行 git cherry-pick abc123 后如果失败，Git 不会自动提交，也不会静默跳过。它会停在冲突点，并把冲突文件标记为 Unmerged paths。此时运行 git status，你会看到类似这样的输出：
Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/utils.js
both modified: package.json
注意两点：一是没有 “modified” 或 “new file”，而是明确写 “both modified”；二是提示你用 git add 来标记“已解决”——这不是可选建议，而是必须步骤。
- 冲突文件里会出现标准三段式标记：
、<code>=======、>>>>>> abc123 -
git diff此时默认只显示工作区与暂存区的差异，看不出原始冲突上下文；要用git diff --ours或git diff --theirs分别看当前分支和被 pick 提交的版本 - 不要直接
git commit—— 这会生成一个 author 为当前用户的普通提交，丢失原始作者、时间戳和(cherry picked from commit ...)标记
解决完冲突后必须用 git cherry-pick --continue
手动编辑完所有冲突文件、删掉标记、确认逻辑正确后，不能靠 git commit 结束流程。Git 正在维护一个内部状态，保存着原始提交的元信息（比如作者、原始提交信息、CHERRY_PICK_HEAD 引用），只有 git cherry-pick --continue 才会读取它并生成合规的新提交。
- 执行
git add src/utils.js package.json把解决后的文件加入暂存区 - 再运行
git cherry-pick --continue，Git 会自动复用原始提交的 author 信息、补上-x标记（如果当初用了该选项）、保留原始提交信息（除非加了--edit） - 如果中途想放弃，用
git cherry-pick --abort，它会把工作区和索引恢复到 cherry-pick 开始前的状态 -
git cherry-pick --skip是跳过当前这个有冲突的提交，继续处理队列里的下一个（适用于批量 cherry-pick 场景）
为什么没改过同一行也会冲突
很多人以为“我根本没碰过这个文件，怎么会冲突”，结果打开一看真有 。根本原因在于 cherry-pick 不是比较“谁改了哪一行”，而是尝试把“源提交相对于其父提交的 patch”打到当前 HEAD 上。如果目标分支的文件结构已经变化（比如该文件被重命名、删除、或所在目录被移动），哪怕内容完全没动，Git 也无法定位 patch 应用位置，就会报冲突。
- 典型场景：
abc123修改了src/api/auth.js，但当前分支里这个文件已被移到src/services/auth.js - 验证方法：
git show abc123:src/api/auth.js看原始内容，再git ls-files | grep auth查当前分支实际路径 - 这种冲突无法靠“选 ours/theirs”一键解决，必须手动把改动迁移到新路径，然后
git add新文件、git rm旧文件（如果适用）
批量 cherry-pick 出现多个冲突怎么应对
当你运行 git cherry-pick a1b2c3 d4e5f6 g7h8i9，Git 是按顺序逐个应用的。第一个冲突出现后，后续提交不会继续尝试，整个操作就卡住。你必须先解决当前冲突、--continue，才能轮到下一个。
- 不要试图一次性解决全部冲突再继续——Git 不允许。每个提交都是独立状态机
- 如果某一个提交实在难解（比如依赖未 pick 的前置提交），可用
git cherry-pick --skip跳过它，后续提交仍可继续 - 想预判哪些提交可能冲突？先用
git cherry-pick -n <commit></commit>（-n表示 no-commit），观察是否报错，不实际写入历史，适合测试性探路 - IDE 如 PyCharm 在冲突时会高亮显示三方对比视图，比命令行
vimdiff更直观，但底层仍是同一套冲突标记机制
真正容易被忽略的是 CHERRY_PICK_HEAD 文件的存在——它就躺在 .git/CHERRY_PICK_HEAD 里，记录着原始提交 SHA。只要没 abort，这个引用就一直有效；一旦 abort，它就被清除。这意味着，如果你解决完冲突却误用了 git commit，author 信息就永远找不回来了，只能 --abort 重来。
