Bob克隆项目并从master创建本地分支A.

Bob添加了一些有用的帮助程序类清理/重构单元测试设置,并通过它们清理所有正在进行的测试.

Bob提交,推送到远程服务器,然后创建一个pull请求,以便从John获得对此重构的代码审查.

领导该项目的约翰忙了一个星期,所以无法立即审查.

在要求进行代码审查之后,Bob想要编写一些全新的测试文件和一组类,最后是另一个单独的pull请求,因为它被认为是在处理新功能.
显然,Bob希望将他的新助手用于那些测试文件.

采用哪种策略：

>对于那些新的单元测试,Bob应该创建一个从master而不是A派生的B分支,因为A还没有被审查.缺点是他不能使用他的单元测试帮助器,因为不存在于B.
> Bob应该等待第一个pull请求的代码审查,合并到master,然后从master派生B.在此期间,他应该专注于其他不依赖于他之前的拉动请求的作品.
>鲍勃应该从A派生B并使用这些助手,承担审查后不接受A的风险.显然导致拒绝B.
>约翰应该动摇他的屁股,作为一个好的领导者,应该在短时间内审查第一个拉动请求,以便鲍勃能够连锁.

处理串行多个拉取请求之间的依赖关系有什么好的做法？

最佳答案 没有必要依赖并等待当前的拉取请求(PR).根据您的情况,Bob希望在处理PR(已发布且尚未批准)之后继续开发/测试基于分支A的内容.他只需要在分支A上开发代码,然后提交&推到远程.将分支A合并到主服务器的PR将自动包含Bob的第二次更改.

因此,对于多PR情况,如果要更新已经在pull请求中的分支,则只需要提交&推送更改,以前的PR可以自动更新.如果要更新处理PR中未包含的分支,则需要提交&推送更改,然后创建一个新的PR,它对以前的处理PR没有影响.

如果您只想添加一些微小的更改或功能本身,您应该在分支A上进行更改并使用处理PR.如果需要开发新功能,则应在新功能分支上进行更改并创建新PR.

对于Bob的条件,开发新功能并需要在分支A上使用帮助程序,因此他应该从A开始分支B甚至A尚未被审查.因为开发人员需要考虑如何开发新功能,并且在之前的PR获得批准之前开发新功能效率不高.或者,如果您的团队确实需要使用这种方式,您仍然可以从A派生B并根据您的需要派生B分支B.