处理顺序拉取请求之间依赖的好策略

Question

鲍勃克隆项目并从主分支master创建本地分支A。

鲍勃添加了一些有用的帮助程序类，清理/重构单元测试设置，并借助它们清除了所有现有测试。

鲍勃提交并推送到远程服务器，然后创建拉取请求，以便约翰对此重构进行代码审核。

由于项目负责人约翰很忙，所以他无法立即审核。

在请求代码审核后，鲍勃想编写一些全新的测试文件和一组类，并以另一个独立的拉取请求结束，因为这被认为是正在开发新功能。 显然，鲍勃希望在这些测试文件中使用他的新帮助程序。

应采取哪种策略：

• 对于这些新的单元测试，鲍勃应该从master派生B分支而不是A，因为A尚未经过审查。缺点是他还不能使用他的单元测试助手，因为在B中不存在。
• 鲍勃应该等待第一个拉取请求的代码审核，合并到master，然后从master派生B。在此期间，他应该专注于与不依赖于先前的拉取请求相关的其他工作。
• 鲍勃应该从A派生B并使用这些助手，冒着A在审核后被拒绝的风险。显然会导致B也被拒绝。
• 约翰应该抖动屁股，并作为一名好领导人，应在短时间内审查第一个拉取请求，以便鲍勃可以连续工作。

处理多个依次拉取请求之间依赖关系的良好实践是什么？

- Mik378

---

很好的问题。我会选择第三个选项。Bob应该从A中派生B并使用那些辅助工具，冒着A在审核后不被接受的风险。显然会导致B被拒绝。Bob总是可以回去修复分支A中的错误。 - MMalke

Answer 1

不必依赖和等待之前的拉取请求(PR)。对于你的情况，Bob想要在处理中的PR(已发布但未获得批准)后基于分支A继续开发/测试某些内容。他只需要在分支A上开发代码，然后提交并推送到远程。将分支A合并到主分支的PR将自动包含Bob第二次更改的内容。

因此，在多个PR的情况下，如果您想更新已经在拉取请求中的分支，您只需要提交并推送更改，以前的PR可以自动更新。如果您想更新不包含在处理中的PR中的分支，则需要提交并推送更改，然后创建一个新的PR，这对之前的处理中的PR没有影响。

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

对于Bob的情况，他需要在分支A上派生出分支B，并需要使用帮助程序。即使分支A尚未审核，也应该这样做。因为开发人员需要考虑如何开发新功能，而在之前的PR获得批准之前开发新功能是不高效的。或者，如果您的团队确实需要使用这种方式，您仍然可以从分支A派生出分支B，并根据您的需求重新定位分支B。

- Marina Liu

---

我完全同意，并且我会和我的团队一起这样工作。问题在于，我在24小时前与我附近的技术领导进行了讨论，他告诉我：“不……如果PR得到更新，无关文件（“功能”混合）的数量将增加，对于我来说一次性对整个代码进行一个代码审查可能非常困难（一次性更改/添加太多文件）……所以我建议他们编写第二个完全独立的pull request。”这可能是一个好的做法，这就是为什么我有点困惑并写下了这篇文章。 - Mik378

我在我的OP上更新了有关第二个pull request内容的一些细节。 - Mik378

是的，您可以从需要的分支派生出一个新分支，并创建一个新的PR。我已经更新了我的答案。 - Marina Liu

如果A的审核未被接受怎么办？这将导致从分支C创建一种新的PR，例如“删除helpers”，该PR基于分支B。 - Mik378

即使A不被接受，但它不会影响B和C，因为它们是不同的。B和C有新功能，所以您可以继续为B和C进行PR。 - Marina Liu