为何Git cherry-pick特定场景下无需解决合并冲突？

先看第一个场景的仓库操作流程：

#!/bin/bash

git init

# 初始提交C1
touch a.txt
echo "first commit in a" > a.txt
git add a.txt
touch b.txt
echo "first commit in b" > b.txt
git add b.txt
git commit -m "first commit"

# master分支的第二次提交C2
echo "second main change to a in master" > a.txt
echo "second main change to b in master" > b.txt
git add a.txt b.txt
git commit -m "second commit"

# 从C1切出branch_for_a分支
git checkout -b branch_for_a HEAD~1

此时branch_for_a分支的代码状态完全等于C1（也就是master分支C2的父提交）。当执行git cherry-pick master（本质是把C2提交的变更应用到当前分支）时，Git做的是三方合并：

• 基准版本：C2的父提交C1
• 当前分支版本：C1（branch_for_a的HEAD）
• 要应用的版本：C2

因为当前分支的内容和基准版本完全一致，Git会直接将C2相对于C1的所有变更应用过来——相当于直接用C2的文件覆盖当前分支的文件，自然不存在需要解决的冲突。

再看第二个场景，我们先在branch_for_a上新增了提交C3：

echo "branch a" > a.txt
echo "branch b" > b.txt
git add a.txt b.txt
git commit -m "branch commit"

此时执行git cherry-pick master时，三方合并的对象变成了：

• 基准版本：C1
• 当前分支版本：C3（已经修改了a.txt和b.txt）
• 要应用的版本：C2（同样修改了a.txt和b.txt）

C3和C2都对基准C1的文件做了修改，且修改内容不一样，Git无法自动判断保留哪一份，所以就会提示需要解决合并冲突。

总结来说，cherry-pick是否触发冲突，核心看当前分支的HEAD与目标提交的父提交之间，是否存在和目标提交重叠的修改——如果当前分支和基准版本完全一致，Git会直接应用目标提交的所有变更，不会触发冲突。

内容的提问来源于stack exchange，提问作者Tryer