假设项目名称为 Kafu

目前项目的开发流程

目前项目基本上使用了 GitFlow的方式，原理大致如图：

GitFlow
更详细的请参见 GitFlow

不同的地方在于：

1. 目前存在多个Develop 分支，应对 Kafu项目中的各个子项目，如 :

• develop_A
• develop_B
• develop_C

2. 三个子项目功能独立，各自生成自身的动态库，各自有自己的CI。
3. 三个子项目内部独立发布，各自有自己的CD，通过tag的方式管理。
4. 三个子项目虽然功能独立，发布独立，各自有各自的CI/CD，但会存在公共依赖部分代码。
5. 整体对外发布时候需要将 dev_A/B/C 均合并到Release分支进行对外发布。

gitflow-now-.drawio.png

目前存在的问题

1. 目前假如有公共部分修改，目前需要分别合入到各个dev分支。假如有hotfix也同样。
2. 每次在发布Release时，需要将各个dev_X分支的代码进行合并，解决冲突。
3. 按照目前的发布周期来看，会存在风险滞后集体出现的问题。
4. 目前当需要Release时，CI没法运行全部测试用例即 dev_A, dev_B, dev_C整体去运行。导致在发布时测试滞后。
5. 每次Release过程中的修复可能需要分别合并到 dev_A, dev_B, dev_C。
6. Release 之后的Hotfix可能需要分别合并到dev_A, dev_B, dev_C 。

未来存在的问题

1. 如果需要兼容不同的架构/OS，对代码的改动，该如何管理维护？
2. 如果需要针对不同的架构/OS做对应优化，该如何管理维护？
3. 不同OS出包如何管理

如何解决/缓解存在的问题

问题	解决/缓解方式	注意点
公共修改部分	直接发起mr到master	Review需要严格
Release发布时	直接从dev分支checkout出Release分支	dev分支需要稳定
发布周期长，合并代码存在风险滞后	dev_A，dev_B，dev_C不单独分支，合并为develope分支	CI需要支持，code review 需要严格
hotfix问题	直接合并到，master和develope上	同上
兼容架构/OS	各个软件代码内部进行兼容，合并到开发分支中
针对不同架构/OS的优化	各个软件处理不同架构OS的优化代码，合并到开发分支中
不同OS出包如何管理	单独仓库如package_release 仓库，不同分支区分不同发行版，代码通过submodule引入

鉴于现实情况，暂时的解决思路如下

1. 机器不足
2. CI尚未健全
3. 目前大家开发习惯

内容	细节	Reviewer
dev_X 开发分支依旧保留	各个feature分支在合并入dev_X分支后，删除掉。	Reviewer 为子项目的相关人
公共修改部分，直接向master发起	发起人有责任告知各个子项目进行rebase操作	Reviewer 必须每个子项目负责人都通过
合并到master的MR的要求	必须全量通过dev_X的所有测试用例，不能有新增失败
Release版本	先基于master checkout出来Release-1.0.0对应分支，将 dev_X分支代码通过cherry-pick逐个合入，并发起到master的MR	Reviewer 必须每个子项目负责人都通过
Release过程中出现的问题	公共问题同样合并到master，子项目问题，修复后合并到对应的子项目	公共问题均需要review，子项目问题，子项目负责人
各个子项目仍可保持独立发版本，自行迭代	但迭代过程中必须保证修改公共部分的代码要单独发起，并合并到master。	Reviewer 为子项目相关人员
hotfix	发布到各个生态之后紧急问题修复，由问题相关人员修复评估影响，是否告知各个子项目pick	如果是公共代码问题，则走公共代码修改的流程，其余走各个项目自己合并的流程
Release完成之后	各个子项目需基于master，将Release期间的修改cherry-pick	各个项目负责人需要做这件事
Release版本间兼容	Release版本间尽可能要做到兼容，减少Release分支的数量，如OpenGL4.0必须兼容3.3，即可维护一个最新的Release-gl40分支，对各个生态发布时从该Release分支发布，之前的Release-gl33不再发布（这里的gl33，gl40可以换成v1.0.0 v1.1.0等等）
硬件架构的兼容性问题和操作系统的兼容性问题	在各自项目中通过代码兼容	同样，如果是公共代码，则走公共代码修改的流程，其余走各个项目自己合并的流程
各个架构/OS的优化	在各自项目中通过代码兼容	同上
向各个OS提供包时	必须在各个OS上全量测试用例验证通过

未来的想法：

1. 如果能够在每次发起MR时，CI均能全量运行各个子项目全量测试用例，则可以不需要各个单独的开发分支。
2. 我们的目标是朝向单个dev分支努力，进而省去了每次发布时，各个项目单独合并到Release分支的痛苦，省去了Release过程中的修复要合并到各个dev分支的痛苦，省去了 hotfix 也要合并到各个dev分支的痛苦。这些工作量是巨大的！
3. 为了保持主仓库分支整洁，最好各自fork主仓库，发起MR。这样，主仓库除了 dev 分支和release分支外，再无其它干扰分支。

CI牛逼了，简直是造福全公司，全体程序员！效率是指数级提升！

The End ;