Git分支合并咨询：子分支及A/B分支不同场景下的合并目标选择

咱们来逐个拆解这三个团队协作中常碰到的分支合并问题：

场景1：Branch A尚未合并至master时，Branch B应合并至master还是Branch A？ #

这种情况下必须合并到Branch A，原因很直白：

• Branch B本身就是从A分叉出来的，你的代码逻辑是基于A的功能延伸的，先合并到A能保证父分支的代码完整性，把B的功能整合到A的代码体系里
• 而且A之后还要合并到master，先把B合入A，后续A向master发起PR时，能避免同时处理A→master和B→master的双重冲突，大幅减少冲突处理的成本
• 如果直接把B合到master，相当于跳过了A的代码校验和逻辑整合，很容易出现功能不兼容的问题，后续排查起来也麻烦

场景2：Branch A已合并至master时，Branch B应合并至Branch A还是master？ #

这时候直接合并到master就好：

• 既然A已经合并到master了，master里已经包含了A的所有代码，B原本基于A的依赖已经在master里存在了
• 此时Branch A大概率已经完成了它的使命（除非是长期维护的特性分支，但一般合并后就会被归档或删除），再合并到A已经没有实际意义，直接合到master是最顺畅的路径
• 合并前记得先把master的最新代码拉到B里做rebase或者merge，确保没有冲突再发起PR

场景3：若Branch A和Branch B均已准备好发起Pull Request，应优先处理哪一个？ #

毫无疑问优先处理Branch A的PR：

• 因为B的代码依赖于A的功能，如果先合并B，后续A合并到master时，B的代码可能会和A的新提交产生冲突，到时候还要回头修改B的代码，反而增加额外的工作量
• 先合并A之后，你可以把B的代码基于最新的master（已经包含A的代码）做一次rebase，这样B的PR就能基于最新的代码基线，冲突更少，评审也更顺畅
• 从团队协作的流程来说，父分支的PR先落地，子分支再跟进，能保证代码的层级逻辑清晰，避免出现依赖倒置的混乱情况

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