分支派生分支场景下的Git优质合并策略选型

一、两种工作流的核心差异 #

1. 先合并feature到master，再同步enhancement到master #

• 冲突处理：feature合并到master后，如果master同期有其他成员的提交，enhancement同步（合并/变基）时需要处理与master最新代码的冲突，冲突范围涉及enhancement的修改+master新增内容，复杂度相对更高。
• 提交历史：用变基的话，enhancement的提交会线性排列在master最新提交之后，历史记录更干净；用合并的话，会多一个合并节点。feature的提交会先进入master的历史序列。
• 节奏限制：如果enhancement的PR先被审批，必须等feature合并到master后才能处理enhancement的同步，可能拖慢交付进度。

2. 先合并enhancement到feature，再合并feature到master #

• 冲突处理：冲突只发生在你自己开发的feature和enhancement分支之间，逻辑更熟悉，冲突范围更小，处理起来更高效。
• 提交历史：feature分支会整合enhancement的所有提交，最终合并到master时，是一个包含完整功能+增强的集合。如果后续enhancement有迭代修改，直接合并到feature即可，不用来回同步master。
• 节奏限制：如果feature的PR先通过但enhancement还没完成，你需要从master拉新分支承接enhancement的后续开发，重新同步代码会有点繁琐。

二、怎么选更合适？ #

看你的团队流程和PR审批的大概率节奏：

• 如果feature的PR很大概率先过审：优先选第一种。等feature合并到master后，给enhancement做变基（git rebase master），让enhancement始终基于最新主分支，后续合并到master时冲突更少，提交历史也更符合团队规范。
• 如果enhancement的PR可能先过审，或者你想把功能+增强作为一个整体交付：优先选第二种。把enhancement合并到feature，两个分支的修改整合在一起，只要feature的PR通过，就能一次性把所有代码推到master，减少重复操作。

另外，如果团队要求所有开发分支必须基于master，第一种方式更合规；如果两个分支都是你自己维护，第二种方式灵活度更高，冲突处理成本更低。

三、关于测试触发的情况 #

不管用哪种方式，只要分支代码发生变更（合并/变基都会修改分支的提交历史或内容），都会触发新的测试：

• 第一种流程：feature合并到master时，master代码变更会触发master的测试（如果有配置）；之后把master合并/变基到enhancement时，enhancement分支代码被修改，会触发enhancement的测试。
• 第二种流程：enhancement合并到feature时，feature代码变更触发feature的测试；后续feature合并到master时，master代码变更触发master的测试。

注意：有些CI工具会检测提交哈希值，变基会改变提交的哈希，哪怕代码内容和之前一致，也会触发测试；合并操作哪怕没冲突，新增的合并提交也会触发测试。

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