使用gitsubmodules的超级项目如何处理长生命周期分支集成问题

方案2更适配你们团队当前的管理诉求和业务场景。

方案1的核心缺陷 #

• 会大幅拉长SM功能分支的生命周期，违背你们「分支生命周期越短越好」的管理规则。
• 所有SP的适配进度高度耦合，只要有一个SP的适配排期靠后，整个SM的变更就会被阻塞，完全不符合你们「短期投入完成大规模环境变更、换取长期收益」的目标。

方案2的合理性及落地注意事项 #

方案2既可以保障SM侧的变更效率，也能兼顾SP侧的发布灵活性，落地时需要明确以下规则避免管理混乱：

1. SM合入破坏性变更规范
   • 合入时必须在commit信息标注[BREAKING CHANGE]标识，同时同步完整的适配操作指南，降低各SP的适配成本
   • 变更合入后第一时间通知所有SP的维护人，明确适配的截止时间要求
2. SP侧临时分支使用规则
   • 仅正在进行版本发布的SP可以申请基于SM旧版本提交拉取临时分支，临时分支只允许合入发布相关的bugfix，禁止叠加新功能开发
   • 临时分支必须设置明确的销毁时间，对应版本发布完成后，必须在规定时间内完成适配，切回SM的develop分支，避免产生大量长期存活的碎片化分支
3. 通用适配规则
   • 所有SP的submodule必须绑定具体commit哈希，不要直接追踪SM的分支名，避免未适配的SP误拉到破坏性变更导致本地环境故障

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