TFS(Azure)非常规分支模式合并冲突优化及Master/Dev引入时机咨询

Branch C启动前的冲突规避策略 #

• 基准分支对齐预处理：在拉取Branch C之前，先把暂不上线的Branch B的变更，以cherry-pick的方式挑选独立、不影响生产的公共基础变更（比如底层工具类、通用组件修改）合并到Branch A里。这样后续Branch C从Branch A拉出的时候，已经包含了Branch B的通用修改，同时让Branch B和Branch C拥有明确的公共祖先节点，从根源上避免Headless merge问题，后续合并Branch B到D的时候，重复变更的冲突会直接消失。
• 变更隔离标记：对Branch B里暂时不能合并到A的业务变更，拆分出独立的提交节点，每个提交都加明确的注释标记，同时整理一份变更清单，标注每个提交涉及的文件路径、业务逻辑范围。后续Branch C开发过程中，对应路径的修改可以提前同步给Branch B的维护人，两边避免对同一逻辑块做重复修改。
• 启用TFS的分支策略限制：在Branch C上配置拉取请求（PR）强制校验规则，要求所有提交必须走PR合入，禁止直接推送；同时开启冲突预检，PR创建时自动检测是否和Branch B的变更存在文件重叠，提前预警冲突风险。
• 定期预合并演练：Branch C开发周期内，每两周做一次Branch B到当前Branch C HEAD的预合并，记录冲突点，同步给两边的开发人员提前调整代码，不要等到最后合入Branch D的时候再集中处理。

引入Master/Dev分支管理理念的合适时机 #

• 当前迭代（Branch C）上线完成后是首个最佳窗口期：此时刚完成一个完整迭代的上线，没有待上线的积压变更，可以直接把上线后的Branch C设为首个Master分支，再从Master拉出Dev分支作为后续迭代的公共开发基线，调整成本最低。
• 团队出现合并冲突相关故障时：比如某次合并导致线上问题、或者单次冲突处理占用了超过1人/天的工作量时，用实际的成本损失作为论据，更容易说服团队接受新的分支策略，推行阻力最小。
• 团队版本管理需求升级时：比如后续要支持多版本并行开发、热修复需求变多、需要统一的回滚机制时，顺势提出Master/Dev的分支方案，匹配团队的实际需求，更容易落地。

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