如何在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分支中，那么我们在patch分支上进行此操作，然后将其合并到Feature和master分支中。 / p>

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

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

Answer 1

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

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

如果您事先知道需要对多个分支（并且正在使用Git）进行一些更改，则可以回到最早的可以进行更改的提交，根据我们对“被应用”，将在其他分支从该提交派生之前，然后从该点创建一个 new 分支。然后，您可以进行更改并提交。这将产生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中对源树没有影响：{ {1}}与原始补丁F2中的匹配。即使在P之后的 feature上也有提交，例如：

P

如有必要，我们可以使用 M1---------M2 <-- master / / A----------P' <-- patch \ \ F1--P--Q---F2 <-- feature 合并到feature中，以避免“撤消”某些更改或出现某种合并冲突。 合并到-s ours的目的是让Git意识到feature和master的共同祖先现在提交feature的事实。 提交P' 必须存在，即使我们仅出于此目的而创建它。 创建它的最简单方法是使用P'。

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