PR审核中Hotfix分支未合并时，Feature分支依赖修复的最佳实践

场景说明 #

当前Git分支结构如下：

hotfix (Branch A) --- PR into dev under review
         /                            V
 1---2---3---4-----------------------dev (or main)
   \
     x---y---z feature (Branch B)

Branch A的hotfix处于PR审核阶段，尚未定稿合并到dev/main；但Branch B的开发完全依赖该修复才能推进——直接合并/cherry-pick A到B，后续若A的PR需要修改，会导致B的代码出现冲突或不一致；暂停B开发又会造成进度延迟。

以下是几种可行的解决方案：

可行方案 #

1. 临时同步修复+主动跟进更新 #

将Branch A的hotfix cherry-pick到Branch B，同时在B的代码或PR描述里明确标记：此修复来自审核中的Branch A，后续需同步A的更新。当Branch A的PR有修改时，及时在B中重新cherry-pick最新的修复提交，或者用git rebase基于更新后的A调整B的提交记录。

• 优势：不中断B的开发进度；
• 劣势：需要持续关注A的PR状态，可能要多次调整代码。

2. 拆分任务，先推进独立模块 #

如果Branch B有不依赖该hotfix的功能模块，先集中开发这部分内容，等待Branch A合并到dev/main后，再将dev/main合并到B获取正式修复，继续开发依赖部分。如果B的所有内容都依赖修复，此方案等同于暂停开发。

• 优势：完全规避后续修复变更带来的冲突风险；
• 劣势：若B无独立模块可开发，会导致整体延迟。

3. 用临时分支隔离依赖 #

从Branch A拉出一个临时分支（例如temp-hotfix-b），将这个临时分支合并到Branch B。等Branch A的PR通过并合并到dev/main后，先把dev/main合并到temp-hotfix-b同步最终修复，再将temp-hotfix-b合并回B，最后删除临时分支。

• 优势：把临时依赖和B的功能代码隔离开，后续更新时逻辑更清晰；
• 劣势：多了一个临时分支的管理成本。

4. 本地临时复制修复代码 #

如果hotfix的代码量不大，直接在Branch B中手动复制一份A的修复代码，添加醒目的注释标记这是临时模拟修复，后续需替换为正式合并版本。等A合并到dev/main后，删除手动添加的代码，合并dev/main到B获取正式修复。

• 优势：不需要关联分支，快速解锁开发；
• 劣势：修复代码复杂时容易出错，后续需要仔细核对替换。

5. 优先推动PR审核 #

和团队负责PR审核的成员沟通，说明Branch B的阻塞情况，申请优先审核Branch A的PR，尽可能缩短等待时间。

• 优势：从根源解决阻塞，无需额外分支操作；
• 劣势：依赖团队协作效率，不一定能快速落地。

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