11

我正在向项目提交两个独立的新功能作为拉取请求。每个功能都在一个主题分支中，每个分支都从 master 的尖端分支。

          /-- feature1
master ---
          \-- feature2

问题是，虽然任何一个分支都可以自己干净地合并到 master 中，但当第二个分支合并时，它会产生冲突。这并不是因为这些特性相互依赖，它们只是碰巧接触了相同的代码。

一个简单的例子：如果原始文件是一个逗号分隔的列表，并且每次提交都想向其中添加一个新项目，它可能看起来像这样：

master:
a,
b,
c

feature1:

- c
+ c,
+ d

feature2:

- c
+ c,
+ e

归根结底，如果两个拉取请求都被接受，则 d 和 e 最终都应该以任意顺序添加到列表中（因为这些功能是完全独立的，所以它们不相互依赖）。但是，如果您尝试将它们都拉进来，则会发生冲突。

处理这个问题的最佳方法是什么？feature2 是否应该基于 feature1 的末尾，然后它们应该以正确的顺序合并到 master 中？

master ---
          \--- feature1
              \------ feature2

如果我这样做了，对 feature2 的拉取请求会只显示 feature2 提交，还是会显示所有 feature1+feature2 提交？

或者我应该在 feature1 合并到 master 之后重新调整 feature2 ？

4

2 回答 2

6

由于这两个功能都不是建立在另一个功能上的，因此您应该像原来那样从 master 分支出来。即使他们接触了一个公共文件（微不足道），这也是如此。

然后在第一个 (feature1) 与原始 master 合并后对第二个拉取请求 (feature2) 进行 rebase（或者如果 feature2 先合并，则 rebase feature1）。

git fetch upstream
git rebase upstream/master feature2

在这里，我们从上游（您从中分叉的原始源）获取提交，然后使用其提交重新定位我们的本地功能分支。

然后修复您可能遇到的任何合并冲突，并将该提交推回您的 fork。对 feature2 的拉取请求将更新，现在包括一个修复可能的合并冲突的提交，并使合并回原来的更清晰/更容易。

或者原始存储库只会抓取您的两个拉取请求分支并将它们合并到自己中，从而解决可能出现的任何冲突。

于 2013-09-02T05:11:41.107 回答
0

feature2 是否应该基于 feature1 的末尾，然后它们应该以正确的顺序合并到 master 中？

8 年后（2013-2021），请注意 GitHub 使用合并队列的概念帮助回答了这个问题：

Pull Request Merge Queue Limited Beta（2021 年 10 月）

为什么要合并队列？

保持高速并保持主分支绿色在今天可能是一个挑战。许多存储库试图通过要求所有拉取请求在合并之前与主分支保持最新来做到这一点。
这确保了主分支永远不会更新为未通过所有必需状态检查的提交，但会迫使开发人员多次更新（或变基）其拉取请求分支，然后等待状态检查完成，然后再尝试再次合并。

在某些项目中，状态检查可能需要 30 分钟或更长时间，如果在此期间合并另一个拉取请求，则该过程会重新开始（对所有人而言）。这可能会对团队的整体速度产生重大影响，并使开发人员更难进行下一个任务。

Merge Queue 的好处是在合并之前要求拉取请求分支是最新的，但不需要开发人员完成这个过程。

这个怎么运作

合并队列的工作原理是并行验证标识为“准备合并”的拉取请求的不同组合，以便拉取请求可以有效地合并，而不会出现当今合并之间存在的典型延迟。

合并队列演示的 GIF

一旦拉取请求被批准并通过了所有必需的状态检查，在存储库中具有写入权限的用户可以将拉取请求排队以进行合并。
拉取请求分支在排队之前不需要与基本分支保持同步。然后，合并队列会创建一个临时分支，其中包括拉取请求和队列中位于其前面的任何非失败拉取请求。
这个分支基于最新版本的基础分支，如果它通过了所有必需的状态检查，基础分支的历史将看起来像这样。
假设它确实通过了这些检查，则基本分支将被快速转发，并且拉取请求被标记为已合并。

于 2021-10-28T21:46:06.960 回答