git - 处理顺序 pull 请求之间依赖关系的好策略

Question

Bob 克隆项目并从 master 创建一个本地分支 A。

Bob 添加了一些有用的帮助程序类来清理/重构单元测试设置并清理所有现有测试，这要归功于它们。

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

领导该项目的约翰忙了一个星期，因此无法立即对其进行审查。

在请求代码审查后，Bob 想要编写一些全新的测试文件和一组类，以另一个单独的 pull 请求结束，因为它被认为是在开发一项新功能。
显然，Bob 想使用他的新助手来处理这些测试文件。

采用哪种策略:

• 对于那些新的单元测试，Bob 应该创建一个从 master 派生的 B 分支，而不是 A，因为 A 尚未审核。缺点是他还不能使用他的单元测试助手，因为 B 中不存在。

• Bob 应该等待第一个 pull request 的代码审查， merge 到 master，然后从 master 派生 B .在此期间，他应该专注于不依赖于他之前的 pull request 的其他工作。

• Bob 应该从 A 派生 B 并使用这些助手，冒着 A 在审查后不被接受的风险.显然导致拒绝 B。

• John 应该振作起来，作为一个好的领导者，应该在短时间内审查第一个 pull 请求，以便 Bob 可以链接。

处理多个串联 pull 请求之间的依赖关系的最佳做法是什么？

Answer 1

没有必要依赖和等待您当前的 pull 请求 (PR) 上一个。对于您的情况，Bob 希望在处理 PR(已发布但尚未批准)后继续开发/测试基于分支 A 的内容。他只需要在分支A上开发代码，然后commit & push到远程即可。将分支 A merge 到 master 的 PR 将自动包含 Bob 的第二次更改。

所以对于多个PR的情况，如果你想更新已经在pull request中的分支，你只需要commit & push changes，之前的PR会自动更新。 如果要更新未包含在正在处理的PR中的分支，您需要提交并推送更改，然后创建一个新的PR，这对之前正在处理的PR没有影响。

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

对于Bob的情况，开发新功能需要在分支A上使用helpers，所以他应该从A派生分支B甚至A 尚未审核。因为开发人员需要考虑如何开发新功能，而在之前的 PR 获得批准之前，开发新功能是没有效率的。或者，如果您的团队确实需要使用这种方式，您仍然可以从 A 派生 B 并根据需要重新设置分支 B。