处理大量拉取请求

我目前正在与一个使用git工作流程的团队一起进行项目。这非常简单，master应该处于可部署状态，并且分支用于创建功能和修补程序。每当我们完成并测试了功能或错误修正后，我们就会尽快将其移交给母版。想法是分支应该尽可能小，以使其更易于合并回主节点。我们有一个政策，即任何推送到master分支的代码都应处于可部署状态并通过测试。

我们遇到这样的情况，其中一个开发人员在一个分支上做了很多工作（几个月的价值），而这个分支还没有被合并回master。现在，该分支上有一些单独的功能和大量提交，实际上，该分支确实应该已经合并了几次，但到目前为止还没有合并。大多数代码处于良好的状态，可以将单元测试合并回到主测试中，但是最近的更改肯定不应该如此，因为它们尚未完成且未经测试。

处理这样一个分支实际上与另一个分支相距甚远的情况的最佳方法是什么？将来，我们可以通过哪些方式避免分支从master获得大量提交？

让几个月没有合并的开发人员修复它。也许他们可以得到一大块代码来合并，也许他们可以得到一堆小块来一次合并。无论如何，他们应该尽一切努力解决问题，因为这是造成问题的原因。

处理这样一个分支实际上与另一个分支相距甚远的情况的最佳方法是什么？

通常，不必担心：这是另一个开发人员的问题。如果两个分支是真的离得太远，合并，那么他们是不是真的了同一项目的一部分，你有一个事实上的叉。如果它是一个开源项目，那可能甚至不是问题。

如果这个开发人员真的很聪明，并且他们的代码比其他团队的总和更好/更智能/更重要，那么值得把它当作您的问题而不是他们的问题。否则，事实并非如此。

要回答字面上的问题：处理这种情况的最佳方法是不要陷入这种情况。

将来，我们可以通过哪些方式避免分支从master获得大量提交？

确保每个人都注意到几个月来没有合并的开发人员必须解决他们引起的问题。确保每个人都知道，频繁地掌握比不频繁地掌握更容易，因为更少的更改意味着更少的冲突机会。

确保人们知道他们可以从大师那里学习与他人的变化保持同步。

“如果每天合并，突然之间，您将永远无法陷入难以解决的巨大冲突。” -莱纳斯·托瓦尔兹

那句话来自他在Google上的演讲，这是笔录，这是视频。

如果您知道一个提交，并且所有先前的提交都经过了良好的测试，应该进行合并，那么只需从上一个良好的提交中分支出来，然后将新分支与master合并。

如果您有一些要合并的提交，但是它们与其他尚未投入生产的提交穿插在一起，那么我看到两种可能性：

1. 创建新分支，然后选择好提交，与master合并。
2. 尝试将不需要的提交重新设置到顶部（为了安全起见，也许在新分支上）。

至于预防方法，请尝试定义一些有趣的团队规则，例如“一个星期内不与主人合并的人将订购比萨饼一个月”。

首先，看看是否确实存在可以合并或挑选的单独提交，例如@Maciej Chalpuk的建议。如果是这种情况，那么情况实际上还不是那么糟糕，并且我以后不会对此太担心。

但是，如果实际情况是在同一提交内在单个分支中同时开发了多个功能，则处理起来会变得更加痛苦。幸运的是，预防方法是内置的：要求开发人员将每个功能的更改分离到单独的分支中，并在合并请求之前提取请求。您将获得原子合并，并阻止该开发人员在其中进行合并。未来。

分离功能的实际过程完全是手动的。从master创建新分支，并复制与mega分支相关的所有更改。编译，测试功能，推送并发出拉取请求。代码更改混杂得越少，越容易完成。如果他正在为所有人使用一种方法，那么，那就好玩了。他不会再这样做了。

这是一个简单的解决方案。

跟踪此人已实现的功能，并转到该分支上的每个提交（每个功能已更新）。进行此提交并将其与主仓库合并。

让我以示例的形式对此进行分类。

假设：分支A是来自主节点的分支分支A + =分支A +新功能1分支A ++ =分支A +新功能2，依此类推，以此类推

您需要做的是回到：A +分行

进入A +分行，并与Master合并。

现在转到Branch A ++并将其与（Master + Branch A +）合并。

重复直到达到稳定的最终分支A + ... +。

这种方法起初听起来可能违反直觉，但是如果您将每个单独的新功能与主功能单独合并，则很容易在主分支“ 每个已添加功能 ” 之间循环

将来，我们可以通过哪些方式避免分支从master获得大量提交？

我认为我上面的解决方案表明您将来应该采用哪种方法。为每个分支使用每个功能或每个任务方法。

我建议使用以下方法：

硕士预科和硕士

大师：最终/生产水平。不经常修改。被认为永远稳定

pre-master：将新功能添加到现有代码中的区域。经过全面测试，可以与现有代码库一起使用，并且是其他分支机构可以分叉进行新功能实现的地方。

您还应该尝试捆绑功能并针对版本定位。

指定版本：指定一个任意数字，该数字将充当master分支的占位符。“在V1.0.0中，我们将要实现X，Y，Z功能。V1.0.0也将具有所有这些可用功能：...”

通过维护针对master的版本，它也可以是始终保持“ master”稳定和准备就绪的一种方式。

解决大请求请求的问题是一回事，对此有一些不错的答案。但是对于处理过时的分支机构，您可能需要重新审视处理团队工作的过程。

如果您在Agile或SCRUM框架内工作，那么团队应该真正询问为什么功能未完成并作为迭代/冲刺的一部分进行合并。如果它“太大”以致无法放入迭代中，则应将其分解为较小的块。

这也引发了代码所有权的问题-在您的团队中，单个开发人员是否单独拥有自己的工作，还是整个团队共同努力以确保项目完成？

当然，以上假设您的团队属于某种公司架构。如果这是一个由志愿者贡献的开源项目，那就是另一回事了。通常，此类项目对工作流程的控制较为宽松，但生成可接受的请求请求的责任更多地落在各个贡献者身上。

在许多方面，这成为一个过程问题。也许您需要的过程包括定期（每周还是每月一次）检查长期运行的未合并分支。一些工具使之易于目视检查。例如，在github上，访问“分支”链接，它显示每个分支的前/后距离。