多个特性并行开发，git一次合并

Question

在git graph中有这样的情况：

dev *
     \_ featureA 
      \_ featureB

我请求将每个功能合并到dev 分支。 这两个功能是并行开发的，将同时合并。

分支featureA 的合并请求已被接受，现在当我的同事想要合并featureB 时，他看到了合并冲突，因为在根目录的CMakeLists.txt 中，这两个功能都在文件中添加了一行同一个地方；在featureA:

CMakelists.txt:10:
    add_subdirectory(featureA)

在featureB:

CMakelists.txt:10:
    add_subdirectory(featureB)

问题是他应该手动解决这个合并冲突，还是我应该在本地重新设置分支featureB，然后重新推送分支，或者工作流程中可能有问题，遇到这种情况时应该采取其他方法？

Answer 1

首先让我说，这里没有正确或错误的解决方案 — 处理此类合并冲突的方式取决于 featureB 的分支类型。

选项 1：如果 featureB 是私有分支，则变基

如果 featureB 是一个 private 分支——这意味着你是唯一一个提交它的人——那么我建议你在 featureA 之后将它重新设置在 dev 之上合并。

这意味着从这里开始：

A--B---M dev
 \    /
  C--D featureA
   \
    E--F featureB

到这里：

A--B---M dev
 \    / \
  C--D   E--F featureB

请记住rebasing is still a kind of merge，区别在于git-rebase 一次应用一个提交 在前一个之上，而git-merge 将两个提交与其整个集合单个操作中的更改。

执行变基会强制您解决冲突在引入冲突更改的提交。这有几个优点：

1. 它为您提供有关更改的更多背景信息，从而更容易找到解决方案。
2. 解决方案将成为提交本身的一部分——它所属的地方——而不是最终合并提交，可能会与其他不相关的冲突解决方案混在一起。

选项 2：如果 featureB 是公共分支，则合并

然而，如果featureB 是一个public 分支——也就是说，有多个人提交给它，那么你不能变基它，因为那将是rewriting history。在这种情况下，您最好在 dev 分支上的常规合并中处理合并冲突。

生成的历史记录将如下所示：

A--B---M------N dev
 \    / \    /
  C--D   E--F featureB

N 是您解决冲突的位置。