并行开发多个功能，同时进行git合并

Question

在git图中有这样的情况：

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是私人分支

，则为rebase

如果featureB是私有分支 - 意味着您是唯一承诺它的人 - 那么我建议您在dev之后将其重新绑定在featureA之后{1}}已合并。

这意味着从这开始：

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合并两个在一次操作中提交他们的整个更改。

执行rebase会强制您解决冲突 引入冲突更改的提交。这有几个好处：

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

选项2：如果featureB是公共分支

，则合并

但是，如果featureB是公共分支 - 也就是说，有多个人提交了它，那么就不能对其进行重新绑定，因为那将是rewriting history。在这种情况下，您最好在dev分支上的常规合并中处理合并冲突。

结果历史将如下所示：

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

其中N是您解决冲突的地方。