git - 如何在 git 中进行部分 merge ？

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

这篇文章解释了为什么 cherry-pick 是邪恶的，以及如何用部分 merge 来代替它。这是图片:

它的意思是，如果我们需要在特性分支中进行更改，而这也必须在主分支中，我们在补丁分支上进行，然后将其 merge 到特性分支和主分支中。

但这意味着我们事先知道更改也必须在 master 中。这篇文章没有解释如果更改最初 checkin 到功能分支中该怎么办，只是后来我们发现它也必须在主分支中。

那该怎么办？如何仅将此更改 merge 到主控？请不要 cherry-pick 。

Answer 1

(正如一些人所指出的，Git 中没有部分 merge 这样的东西。)

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

如果您事先知道需要将某些更改应用到多个分支(并且正在使用 Git)，您可以回到最早可以进行更改的提交——根据我们对“被应用”，将在此提交的其他分支分支之前 - 并从该点创建一个 new 分支。然后，您可以进行更改并提交。这会产生 patch 分支(请参阅陈先生在第三篇文章中显示的图表，您已将其复制到问题中)。

然后您可以将这个新分支 merge 到所有其他分支中，如此处(和此处)所示。

But it implies that we know beforehand that the change will have to be in the master too.

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

The post does not explain what to do if the change is originally checked in to the feature branch and only later do we discover it has to be in [another] branch as well.

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

What to do then? How to merge only this change to the [other branch]? No cherry picking, please.

我们这样做的方法是识别祖先提交(无论它可能在哪里)并进行挑选。 (对不起!)cherry-pick 创建了一个仅在补丁分支上的新提交。然后我们将补丁分支 merge 到两个分支中，就好像我们第一次做了正确的事情一样。这会产生以下结果:

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

请注意，将 patch merge 到 feature 对 在 F2 on 的提交中对源代码树没有影响>feature:F2 中的源代码树与原始补丁 P 中的源代码树匹配。即使在 feature after P 上有提交也是如此，例如:

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

如有必要，我们可以使用 -s ours merge 到 feature 以避免“撤消”某些更改或发生某种 merge 冲突。 merge 到 feature 的目的是让 Git 意识到 master 和 feature 的共同祖先。现在是提交 P'。 提交 P' 必须存在，即使我们必须为此目的创建它。 创建它的最简单方法是使用 git cherry-pick。

cherry-pick 是一种工具，而不是解决方案。陈先生的博文指出，人们使用该工具很糟糕。这并不意味着工具本身不好!