如何在git中进行部分合并？

Question

这个问题的灵感来自以下出色的帖子：https : //blogs.msdn.microsoft.com/oldnewthing/20180312-00/ ? p = 98215 https://blogs.msdn.microsoft.com/oldnewthing/20180313-00/ ？p = 98225 https://blogs.msdn.microsoft.com/oldnewthing/20180314-00/?p=98235

这篇文章解释了为什么采摘樱桃是邪恶的，以及如何用部分合并代替它。这是图片：

其含义是，如果需要对功能分支进行更改，而该更改也必须位于master分支中，则在补丁分支上进行更改，然后将其合并到Feature和master分支中。

但这意味着我们事先知道更改也必须在主数据库中。这篇文章没有说明如果更改最初是在功能分支中签入的，该怎么办，直到后来我们才发现更改也必须在master分支中。

那该怎么办？如何仅将此更改合并到主服务器？请不要摘樱桃。

Answer 1

（正如几个人所指出的，Git中没有部分合并的东西。）

我不是原始博客文章的作者，不能为他讲话，但是我会说他总体上是正确的。鼓舞人心的例子有点愚蠢，但是当人们试图做一个简单的例子来说明为什么我们可能做一些看起来很复杂的事时，这几乎是不可避免的。

如果您事先知道需要对多个分支应用某些更改（并且正在使用Git），则可以回到最早的可以进行更改的提交，这就是我们定义的“被应用” ，将在其他分支从该提交派生之前，然后从该点创建一个新分支。然后，您可以进行更改并提交。这将产生patch分支（请参见Chen先生在第三篇文章中显示的示意图，您已复制到问题中）。

然后，您可以将此新分支合并到所有其他分支中，如此处（此处）所示。

但这意味着我们事先知道更改也必须在主数据库中。

正确。为了采用此策略，我们必须知道该特定补丁程序注定要进入N个分支集中，并找到所有分支中包含的合适的祖先提交。

这篇文章没有说明如果更改最初是在功能分支中签入的，该怎么办，直到后来我们才发现更改也必须在[another]分支中。

没有完美的解决方案，但是有一个足够好的解决方案。但是，它违反了您的投诉：

那该怎么办？如何仅将此更改合并到[other分支]？请不要摘樱桃。

我们这样做的方法是，确定祖先的承诺（无论可能在哪里）并认真挑选。（对不起！）cherry-pick创建了一个仅在patch分支上的新提交。然后，我们将补丁分支合并到两个分支中，就好像我们第一次完成了Right Thing一样。这将产生以下：

(apple)   (berry)
  M1---------M2     <-- master
 /          /
A----------P'     <-- patch
 \          \
  F1------P--F2     <-- feature
(apple)   (berry)

需要注意的是合并patch到feature具有源树上没有影响在承诺F2上feature：源代码树中F2的比赛，在原来的补丁P。即使在feature 之后 有提交，也是如此P，例如：

  M1---------M2     <-- master
 /          /
A----------P'     <-- patch
 \          \
  F1--P--Q---F2     <-- feature

如有必要，我们可以进行合并feature，-s ours以避免“撤消”某些更改或出现某种合并冲突。 这样的合并，为的点feature，就是让Git的意识到一个事实，即共同的祖先master和feature现在提交P'。即使我们必须为此目的创建它， 提交也P' 必须存在。最简单的方法来创建它是使用git cherry-pick。

樱桃采摘是一种工具，而不是解决方案。陈先生的博客文章指出，人们对该工具的使用不佳。这并不意味着该工具本身就是坏的！