Git 长特性分支同步主干后合入的策略可行性咨询

可行性结论 #

你这套设计完全可以落地，本质就是Git分支实践里很成熟的长特性集成分支模型，刚好解决你提到的两个核心痛点：既避免同史诗下零散的子功能提前合入master打乱发布节奏，又通过定期同步主干把大冲突拆成多次小冲突，不会等到最后上线才攒出根本改不动的巨型冲突。
你提到的定期在集成分支执行git merge master的同步方式本身也能跑通，不算错，但绝对算不上最优方案，实际用起来坑不少。

当前merge同步方案的实际问题 #

我接触过不少团队一开始就用这套纯merge的方式，跑几个迭代基本都会遇到这些麻烦：

• 提交历史乱得没法看：集成分支上隔三差五就出现一个「merge master into feature/newFAQPage」的提交，和业务开发提交穿插在一起，后续要排查某个FAQ功能的改动点、或者要回滚某个子故事的代码，翻提交日志要筛半天无效记录
• 冲突改错很难发现：merge的时候如果遇到冲突，经常是负责同步的人自己闷头改完就提交，这类merge提交的代码评审大多是走个过场——毕竟冲突改动混在自动合并的代码里，很难逐行核对，很容易出现「解决冲突的时候把之前调好的FAQ配色冲没了」「把master上别的团队刚修好的bug又改回去了」这类问题，往往要到测试阶段才会暴露
• 最后合主干的时候会把一堆杂乱的merge记录全带到master上，把主干的历史也搅乱，后续做版本挑拣、线上问题回滚都麻烦

更合理的落地方式 #

根据你们团队的规模和Git操作熟练度，可以选下面几种适配方案，没有绝对的对错，选最贴合你们现有流程的就行：

方案1：把同步操作从merge换成rebase（适合中小团队、成员Git基础较好的场景） #

整体流程和你原来的设计基本一致，只需要调整同步主干的操作逻辑：

• 所有开发者的子用户故事分支统一从feature/newFAQPage切出，开发完成走评审合入集成分支，这部分不变
• 定期同步主干时，不要直接merge，切到feature/newFAQPage分支后执行git rebase master，把集成分支上所有FAQ相关的提交整体挪到最新的master提交节点之上
• rebase会改写分支历史，推送到远端的时候必须用git push --force-with-lease，绝对不要用裸的--force参数，避免把其他同事刚推到集成分支上的代码覆盖掉
• 等所有功能开发完，集成分支是直接基于最新master的干净提交序列，没有多余的merge节点，合入master的时候非常顺畅，提交历史也整洁，所有FAQ相关的改动都连续排在一起，后续排查问题效率很高
  这个方案的缺点是rebase有一点学习成本，需要和团队约定好：不要从集成分支切出去拉长期存在的个人分支，不然rebase之后本地分支和远端分叉，新手很容易搞混。

方案2：保留merge逻辑，补充分支保护规则兜底（适合团队规模大、成员Git水平参差不齐的场景） #

如果觉得rebase的学习成本太高，完全可以继续用merge同步的方式，只要补几个规则就能避开90%的坑：

• 给feature/newFAQPage开分支保护，不管是开发者提子功能代码，还是同步master的操作，一律不准直接push，必须走MR/PR流程
• 同步master不要在本地做，直接在代码托管平台发起从master到集成分支的MR，强制要求至少1个熟悉两边业务逻辑的人评审冲突代码，同时必须跑通全量自动化测试（单测、构建、E2E用例）才能合入
• 每次同步完master立刻给集成分支打个临时tag，万一冲突改坏了可以快速回滚到上一个可用状态
• 最后集成分支合入master的时候，选「压缩合并（Squash Merge）」模式，把所有开发、同步的零散提交压成几个（甚至1个）干净的业务提交再合入，不会把杂乱的历史带到master上

方案3：功能开关替代长集成分支（适合master随时可发布、上线频率高的团队） #

如果你们团队的master是要求随时可上线的状态，其实可以从根源上避免长分支同步的麻烦：

• 所有FAQ的子故事开发完直接合入master，但是所有未完成的FAQ新功能都用功能开关（Feature Flag）包裹，开关默认关闭，线上用户完全看不到未做完的内容
• 等所有子故事开发、测试完成，再统一打开开关，实现FAQ功能一次性上线
  这种模式完全不需要维护长期的集成分支，也不用反复同步解决冲突，所有开发都是基于最新master做的，长期维护成本最低，但前提是你们团队有统一的功能开关管理能力，有对应的代码规范要求。

选型不用追求所谓的「最佳实践」：如果团队人少大家Git都用得熟，rebase方案效率最高；如果团队新人多，带保护规则的merge方案最稳妥；如果已经有成熟的开关体系，直接用开关模式最省心。

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