樱桃选择问题:也会应用以前提交的更改

Question

在我的项目中,我几个月前发布了一个版本.在那个版本之后,我在master分支上做了很多更改.

如果我在最后一个版本中遇到一些错误,我会在主分支上修复它们,然后将它们挑选到我在上一版本中创建的分支.然后我可以提供一个只有bug修复的新版本,而不释放master分支上未完成的工作.

当我试图挑选一个错误修复发布分支时,我遇到了合并冲突.

据我所知,cherry选择某个提交会向目标分支引入一个新提交,并在提取的提交中完成更改.

但是,当我尝试修复合并冲突时,似乎git已经在master分支上应用了更改,这些更改不是由我选择的提交提交给我的发布分支.樱桃选择提交只引入了冲突文件的几行.但是,当我尝试解决冲突时,我看到该文件中还引入了其他几行,这些行被添加到具有不同提交的主分支中.

有人可以解释为什么我的发布分支中引入了除了樱桃挑选提交之外的提交更改吗？

Answer 1

据我所知,cherry选择某个提交会向目标分支引入一个新提交,并在提取的提交中完成更改.

那是正确的.但是,这些更改可能不适用,在这种情况下:

...我遇到了合并冲突.

此时,git cherry-pick正在进行三向合并,这需要选择合并基础.

我记得,哪些文件或提交用作合并基础部分取决于您的Git版本.现代Git,如果你运行git cherry-pick,使用樱桃挑选的提交的父亲作为合并基础,但至少有一个表单(使用git am或git apply使用--3way选项,git rebase仍然可以做)可以使用以下index行来选择更早版本的文件git diff输出.最后,这可能不应该太重要.

在任何情况下,合并实际上都会git diff从基本提交运行到两个"提示"(樱桃挑选的提交,以及您尝试应用樱桃选择的HEAD提交)中的每一个.要在视觉上看到正在发生的事情,您应该像往常一样从绘制提交图开始.(我没有你的存储库,所以我会绘制一个不同的图表并希望它足够接近.但是你应该自己绘制 - 或者让Git这样做,或者使用gitk或者使用它.)

          o--@         <-- branch (HEAD)
         /
...--o--o
         \
          I--P--C--o   <-- otherbranch

我在这里给出了各种提交的单字母名称:C是我们即将挑选的提交,P是它的父级.我@在这里标记了当前(HEAD)提交,尽管所有实际工作都将在索引和工作树中进行.(幸运的是git cherry-pick要求索引和工作树是"干净的",除非你-n用来将多个樱桃组装成一个大的选择,所以索引和工作树@无论如何都会匹配提交.)并且,我将提交标记I为"重要" .

现在,考虑如果我们以P作为基础的三向合并,C作为其中一个提交,以及@作为另一个提交,会发生什么.当我们计算变更指令P到C,我们得到了我们想要应用差异:这是非常简单的.但是,当我们计算改变指令P到@,好了,唉.

我们做了一些重要的改变I.这些变化是其中的一部分P,即它们在我们的合并基础中.但他们并不在@.合并的含义是Git会将这些重要的变化视为我们试图取消的事情.事实上,他们是!我们没有挑选I自己,所以我们必须撤消这些I更改才能应用更改C.

无论这些I变化,我们是"撤销"不是@下手,并不会影响任何的距离变化C,我们很好:他们已经撤消.如果由于某些原因或目的,这些一个I变化是在@(可能通过@的母公司),这些都不是,即使在我们努力在第一时间撤消集,如此反复我们很好.这是当这些变化与冲突,甚至只是紧靠成(的情况下),则P至- C变化,我们有问题.

在这种情况下,Git将在两个合并冲突区域之一中显示一些I变化.这些都是我们试图挑选的部分.它们不一定被应用,它们只是我们必须解决的冲突的一部分.如果你设置merge.conflictStyle为 - diff3我通常建议的东西 - I更改将显示为合并基础的一部分,因为合并基础是提交P,它本身基于I(即,P快照包含来自I我们更改它的代码除外)而制作P).

因此,我并不完全清楚你所问的是什么,但在合并冲突区域看到与你正在挑选的位无关的变化是正常的.