这是团队协作里非常典型的场景，尤其是评审周期固定但开发节奏更快的时候，得根据功能的依赖关系来选分支来源，下面分两种核心情况给你具体建议：

一、功能完全独立（比如新增独立控制器、独立页面布局） #

这种情况下强烈建议从master分支创建feature-two，原因有这几点：

• 保持每个PR的独立性：feature-one的代码还没经过评审，可能存在需要大幅修改甚至被否决的情况，如果feature-two基于它开发，后续一旦feature-one变动，你得花额外精力去同步调整，反而增加工作量。
• 降低合并风险：独立分支基于最新的master开发，后续各自合并到master时，冲突概率更低，也方便评审者分开评审两个独立功能，不用在PR里理清楚哪些代码属于哪个功能。
• 举个实际例子：你开发的是用户管理控制器（feature-one）和首页新布局（feature-two），两者完全没交互，那分别从master拉分支，哪怕feature-one在等待评审，feature-two可以正常开发、提交，互不干扰。

二、功能存在关联依赖（比如feature-two需要用到feature-one新增的接口或工具类） #

如果两个功能是强关联的，那可以从feature-one分支创建feature-two，但要注意几个关键操作：

1. 在feature-two的PR描述里明确标注：「该PR依赖#XXX（feature-one的PR编号），请先评审合并feature-one」，避免评审者误操作先合并feature-two。
2. 定期同步feature-one的变更：如果feature-one在评审过程中需要修改，记得及时把feature-one的最新代码merge到feature-two，保持分支同步，减少后续合并时的冲突。
3. 做好回退预案：万一feature-one最终被评审否决，你需要把feature-two里依赖feature-one的代码移除，然后重新基于master创建新的feature-two分支，避免无效代码残留。

额外小技巧 #

• 不管哪种情况，都建议每个PR的代码量尽量小、聚焦单一功能，这样评审者更容易快速理解和给出反馈。
• 如果你在开发feature-two期间，master有其他已合并的变更，记得定期把master的代码merge到你的feature-two分支，提前解决潜在的合并冲突。

内容的提问来源于stack exchange，提问作者Guilherme