考虑我github project（MY）的分叉。它来自上游（美国）：
美国 -fork - ＆gt; 我的：主人
我在本地分支机构（fixA和fixB）中做了一些修复，并将这些分支机构的拉取请求发送到了美国。拉动请求仍在等待在美国合并。 我已将它们合并到MY：master，因为我需要一个包含所有更改的集中位置。
现在另一位同事（HIS）希望帮助解决另一个问题。他问我：主人给他：主人;创建一个fix19分支，将请求拉到MY：fix19。
美国 -fork - ＆gt; 我：主人 - fork - ＆gt;的 HIS：主
然而，当我尝试将请求MY：fix19发送到US：master ...我注意到fixA和fixB＆＃39; s提交也在那里！
问题：处理此问题的最佳策略是什么？我是否需要创建另一个分支MY：teamDev，合并我的拉动请求和HIS的拉动请求，并保持MY：master与US完全相同：master（意味着它将落后直到美国维护人员合并请求？ HIS是否应该从美国分出来：主人而不是我的主人？考虑到这一点，但这也意味着HIS无法访问我的fixA和fixB更改 - 这看起来并不理想。
答案 0 :(得分：0)
然而，当我尝试将请求MY：fix19发送到US：master ...我注意到fixA和fixB＆＃39; s提交也在那里！
当然，因为fixA和fixB未合并到US:master。因此，当您将fix19与US:master进行比较时，fixA和fixB会显示出来。
处理此问题的一个好方法是在为fix19创建拉取请求之前等待。
维护人员合并fixA和fixB后，这些差异将从fix19的拉取请求中消失。
从技术上讲，为fix19创建拉取请求并不重要。您可以立即创建它，也可以稍后创建它，最终结果是相同的。但是如果你以后创建它，它对维护者来说会更好。如果你现在创建它，维护者可能会同时查看fixA和fix19，并惊愕地看到两次相同的事情。更重要的是，他们可能会要求您先在fixA中解决问题。
逻辑上，维护者应该在fixA之前合并fixB和fix19。为了简单起见，请等待fix19的拉取请求。
如果您还有其他不包含fixA和fixB的更改，则可以随时为这些更改创建拉取请求，因为合并它们的顺序并不是＆＃ 39; t（不应该）。
<强>更新
等待待处理的拉取请求并不好玩，因为您必须跟踪未合并的分支。但是，你的或者项目维护者的安慰更重要？
跟踪待处理分支的一种方法是在存储库中临时重命名它们。您可以在创建拉取请求之前将其重命名。
如果上游项目处于非活动状态，您可以继续使用fork作为团队的主要来源。这没什么不对。