cherry-pick冲突后如何查看未提交的修改？

Question

在执行 `git cherry-pick` 时，若引发冲突，Git 会暂停操作并标记冲突文件。此时修改尚未提交，开发者常困惑于如何查看这些未提交的修改内容。常见的问题是：**cherry-pick 冲突后，如何使用 `git diff` 正确查看当前工作区中未提交的修改？是否包含冲突标记？应使用何种参数（如 `--cached` 或不加）来准确识别待修复的变更？** 理解 Git 在冲突状态下的暂存区与工作区差异，是有效排查和继续 cherry-pick 操作的关键。

Answer 1

一、Git Cherry-Pick 冲突后的状态解析

当执行 git cherry-pick <commit> 时，Git 尝试将指定提交引入当前分支。若该变更与当前工作区存在代码冲突，Git 会中断操作并进入“冲突合并状态”（merge conflict state）。此时，相关文件会被标记为冲突，并在文件中插入冲突分隔符（如 <<<<<<<, =======, >>>>>>>），同时 Git 暂停流程等待用户手动解决。

开发者在此阶段尚未提交任何内容，因此所有修改均处于“未提交”状态。理解此时的 Git 三棵树模型——工作区（Working Directory）、暂存区（Index/Staging Area）和 HEAD 提交——是关键。

二、Git 三棵树模型在冲突中的表现

• 工作区：包含带有冲突标记的实际文件内容，即你用编辑器看到的内容。
• 暂存区：Git 在冲突发生后，不会自动将冲突文件添加到暂存区；相反，它使用特殊的“未合并路径”机制记录冲突状态。
• HEAD：指向当前分支的最后一次提交，作为基础版本参与三方合并。

在冲突状态下，暂存区保留了三个版本的信息：

Stage	含义
Stage 0	合并结果（空，因冲突未解决）
Stage 1	共同祖先版本（base）
Stage 2	当前分支版本（ours）
Stage 3	被 cherry-pick 的提交版本（theirs）

三、如何使用 git diff 查看未提交的修改

在 cherry-pick 冲突后，最直接查看当前未提交修改的方式是运行：

git diff

此命令默认比较工作区与暂存区之间的差异。由于冲突文件未被 add 过，其在暂存区仍保留原始内容（或为空），而工作区已写入冲突标记，因此 git diff 会显示完整的冲突内容，包括 <<<<<<< HEAD 等标记。

示例输出片段：

diff --cc file.txt
index abc123,def456..000000
--- a/file.txt
+++ b/file.txt
@@@ -1,5 -1,5 +1,9 @@@
 +<<<<<<< HEAD
  This is the original line.
++=======
+ This is the incoming change from cherry-pick.
++>>>>>>>

四、--cached 参数的行为分析

若使用 git diff --cached，Git 将比较暂存区与 HEAD 之间的差异。但在冲突状态下，大多数冲突文件并未被 git add，因此它们不在 stage 0，--cached 输出通常不包含这些文件。

然而，如果你已经部分解决了某些文件并执行了 git add，那么这些文件将从 stage 1/2/3 转移到 stage 0，此时 git diff --cached 将显示你已解决后准备提交的内容，而不含冲突标记。

总结参数行为：

命令	比较对象	是否包含冲突标记
git diff	工作区 vs 暂存区	是
git diff --cached	暂存区 vs HEAD	否（仅已 add 文件）
git diff HEAD	工作区 vs 最近提交	是

五、高级诊断：使用 git status 和 ls-files

git status 会明确列出“Unmerged paths”，帮助识别哪些文件正处于冲突状态。

更深入地，可使用底层命令查看暂存区的多阶段条目：

git ls-files -u

输出示例：

:1:abc123  file.txt
:2:def456  file.txt
:3:ghi789  file.txt

这表示 file.txt 在 stage 1（base）、stage 2（ours）、stage 3（theirs）均有记录。

六、流程图：Cherry-Pick 冲突排查决策树

graph TD A[执行 git cherry-pick] --> B{是否冲突?} B -- 是 --> C[Git 暂停, 标记冲突文件] C --> D[运行 git status 查看未合并路径] D --> E[使用 git diff 查看工作区变更] E --> F{是否已编辑并准备提交?} F -- 是 --> G[git add <resolved-file>] F -- 否 --> H[继续编辑解决冲突] G --> I[git cherry-pick --continue] H --> E B -- 否 --> J[自动完成 cherry-pick]

七、实际操作建议与最佳实践

1. 冲突后优先运行 git status 确认受影响文件。
2. 使用 git diff 直接查看包含冲突标记的修改内容。
3. 避免使用 git diff --cached 初期排查，因其可能遗漏未 add 的冲突文件。
4. 解决冲突后必须 git add 文件以将其移出未合并状态。
5. 利用 git mergetool 可视化工具辅助解决复杂冲突。
6. 若想放弃当前 cherry-pick，使用 git cherry-pick --abort。
7. 可通过 git log --oneline --graph --all 回顾分支拓扑，理解变更来源。
8. 在 CI/CD 环境中，建议预先 rebase 或 merge 主干以减少冲突概率。
9. 团队协作中应约定冲突解决规范，如注释清理、保留逻辑一致性等。
10. 长期维护项目可启用 rerere（reuse recorded resolution）功能自动复用历史解决方案。