如果历史记录在第二个分支上保持线性，为什么樱桃拣选会检查一个分支的樱桃拣选提交与另一个分支上放置它的提交之间的冲突？我只是想了解挑选冲突背后的内部结构和基本原理，尽管它的所有目的是将提交从一个位置复制到另一个位置。
在 Git 中挑选樱桃的工作方式是它是引擎盖下的合并。 该合并将单个提交中的更改从一个位置应用到另一个位置。
如果该提交包含的更改也与提交所选取到的分支中的更改重叠，则没有简单的方法来解决此问题，因为从被挑选的提交中所做的更改不能完全应用于另一个分支，因此会导致冲突。 这与任何其他合并冲突发生的情况相同：合并的双方在同一个地方都发生了变化，并且无法自动选择应该采用哪一个。
想象一下存储库的结构：
master feature
| |
| |
m1 f1
| /
| /
m2 f2
| /
| /
common
现在我们挑选m1来分支feature。
m1可以依赖于m2所做的一些更改。因此，由于m2更改了一些行m1更改，因此不清楚如果在分支顶部应用相同的更改feature该怎么办。所以这是一个冲突。- 此外，
f1或f2可以对与m1相同的行进行更改。同样不清楚在这种情况下该怎么做，因此用户必须决定应该做什么(解决冲突)。