Bob克隆项目并从A创建本地分支master。
Bob添加了一些有用的帮助程序类清理/重构单元测试设置，并通过它们清理所有正在进行的测试。
Bob提交，推送到远程服务器，然后创建一个拉取请求，以便从John获得对此重构的代码审查。
领导这个项目的约翰忙了一个星期，所以不能马上复习。在要求进行代码审查之后，Bob想要编写一些全新的测试文件和一组类，最后是另一个单独的拉取请求，因为它被视为处理新功能。
显然，Bob希望将他的新助手用于那些测试文件。
采用哪种策略：
对于那些新的单元测试，Bob应该创建一个B分支，该分支来自master而不是A，因为A尚未被审核。缺点是他不能使用他的单元测试助手，因为B中没有。
Bob应该等待第一个请求的代码审核，合并到master，然后从B派生master。在此期间，他应该专注于其他不依赖于他之前的拉动请求的作品。
Bob应该从B派生A并使用这些助手，承担审核后A未被接受的风险。显然导致拒绝B。
John应该动摇他的屁股，作为一个好的领导者，应该在短时间内审查第一个拉动请求，以便Bob可以链接。
处理多个拉取请求之间的依赖关系有什么好处？
答案 0 :(得分：1)
没有必要依赖并等待当前的拉取请求（PR）。根据您的情况，Bob希望在处理PR（已颁发且尚未批准）之后继续基于分支A开发/测试某些内容。他只需要在分支A上开发代码，然后提交＆amp;推到远程。将分支A合并到主服务器中的PR将自动包含Bob的第二次更改。
因此，对于多重PR情况，如果您想要更新已经处于拉取请求中的分支，则只需要提交＆amp;推送更改，以前的PR可以自动更新。 如果要更新处理PR中未包含的分支，则需要提交＆amp;推送更改，然后创建一个新的PR，它对以前的处理PR没有影响。
如果您只想添加一些微小的更改或功能本身，您应该在分支A上进行更改并使用处理PR。如果您需要开发新功能，则应在新功能分支上进行更改并创建新PR。
对于Bob的情况，开发新功能并需要在分支A上使用帮助程序，因此他应该从B派生分支A，即使A尚未审核。因为开发人员需要考虑如何开发新功能，并且在之前的PR获得批准之前开发新功能效率不高。或者，如果您的团队确实需要使用这种方式，您仍然可以从B派生A并根据您的需要重新设置分支B.