Git Merge Branch-对其他分支的特定更改，忽略合并

Question

我想知道是否有一种好方法可以将特定于一个分支的更改合并到另一个分支。

假设我有一个主分支，其中包含更改 A、B、C、D 和 E。我为功能 1 创建了一个功能分支，它将主分支从 B 中分离出来。功能分支具有更改 M 和 N，并且then 与 master 合并回来，使其包含 C' 和 D'，然后添加一个新的 feature2 特定更改 O。 同时，另一个团队创建了另一个从 A 中分离出来的特性分支（特性 2），并进行了 X 和 Y 的更改。我想做的是将特性 1 特定的更改合并到特性 2 分支中，而不获取任何分支 1 特定的更改（因此，在下图中，我想将更改 M、N 和 O 合并到 feature2，但我不想要 B、C、D 或 E...

   A -- B -- C -- D -- E               (master)
    \    \         \ 
     \    M -- N -- (C'/D') -- O       (feature1)
      \                         \
       \                         \
        \-- X -- Y ------------  (M'/N'/O')     (feature2)

现在，在现实生活中，图表要复杂得多（有几个从 master 合并到 feature1 的分支）。有没有办法只抓取特定于 feature1 分支的提交并将它们合并到 feature2 上？ （将 feature1 和 feature2 合并回 master 时会避免冲突？）

Answer 1

您可以通过在特征 2 上挑选 M、N 和 O 来做到这一点：

git switch feature2
git cherry-pick M N O

生成的历史记录将如下所示。请注意，M'、N' 和 O' 在功能 2 上，但功能 2 没有与功能 1 合并。没有合并提交，因此分支之间没有线。

   A -- B -- C -- D -- E               (master)
    \    \         \ 
     \    M -- N -- (C'/D') -- O       (feature1)
      \                         
       \                         
        \-- X -- Y -- M' -- N' -- O'   (feature2)

话虽如此，简单地将功能 1 合并到功能 2 可能是最好的选择，如果您得到更改 B、C、D 和 O 也没关系。这不会再导致合并冲突，当您最终合并回master。

发生合并冲突时

合并冲突并不神奇。只有当作为合并基础的两个提交都更改了大约相同位置的同一个文件时，才会发生合并冲突。

在任何合并之前，让我们再看看您的原始存储库结构：

   A -- B -- C -- D -- E               (master)
    \    \         \ 
     \    M -- N -- (C'/D') -- O       (feature1)
      \                         
       \                         
        \-- X -- Y                     (feature2)

功能 2 和 master 的合并基础是 A，因为这是功能 2 和 master 上的最新提交。您可以使用git merge-base feature1 master 让 git 告诉您合并基数：

# Get commit hash
git merge-base feature2 master

# Get info about the commit that's the merge base
git log -n 1 $(git merge-base feature2 master)

同样，功能 1 和主控的合并基础是 D，因为这是功能 1 和主控上的最新提交。

当你将 feature1 合并到 feature2 时，它现在看起来像这样：

   A -- B -- C -- D -- E               (master)
    \    \         \ 
     \    M -- N -- (C'/D') -- O       (feature1)
      \                         \
       \                         \
        \-- X -- Y -------------- Z    (feature2)

这里，提交 Z 是与父级 O 和 Y 的合并提交。

现在，feature2 和 master 的合并基础是 D。因为 D 被合并到 feature1 中，而 feature1 被合并到 feature 2 中，所以 D 是 master 和 feature 2 上的最新提交。

发生合并冲突的唯一方法是在将 feature2 合并回 master 时发生，如果 E 更改了 feature1 或 feature2 更改的内容。我们不必担心 B、C 或 D，因为它们现在都集成了。

合并冲突不是坏事

合并冲突并不是一件坏事。这只是意味着两个人在不同的分支上编辑了同一文件的同一部分。改组提交不会避免它们，这没关系。项目越成熟，文件越多，发生合并冲突的可能性就越小，因为多人处理同一个文件的可能性较小。

当它们发生时，解决它们（最好在 IDE 中简化，例如 VS Code），然后继续前进。