并行开发的多个功能和 git 一次合并

Multiple features developed in parallel and git merging at once

在git图中出现这样的情况:

dev *
     \_ featureA 
      \_ featureB

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

分支 featureA 的合并请求已被接受,现在当我的同事想要合并 featureB 他看到合并冲突,因为在 CMakeLists.txt 的根目录中features 在文件中的同一位置添加一行;在 featureA:

CMakelists.txt:10:
    add_subdirectory(featureA)

featureB中:

CMakelists.txt:10:
    add_subdirectory(featureB)

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

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

选项 1:如果 featureB 是私有分支

,则变基

如果 featureB 是一个 private 分支——这意味着你是唯一一个致力于它的人——那么我建议你在 devfeatureA 合并后。

这意味着从这里开始:

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

为此:

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

请记住 ,区别在于 git-rebase 在前一个之上应用 一次提交 ,而 git-merge 在单个操作中合并两个提交及其整个更改集。

做变基迫使你解决引入冲突更改的提交的冲突。这有几个优点:

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

选项 2:如果 featureB 是 public 分支则合并

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

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

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

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