总结思路：
如上多分支管理，无非都就是为了解决一个问题：能同时开发新版本(release-1.1.x)和维护旧版本(release-1.0.x)。
试想一下，新版本的功能在提交，旧版本的功能也在提交，如何保证不混乱呢？ 那就引入以上管理模型，以 master 为主(它包含相对最新但不稳定的代码)，然后管理员手动 cherry-pick 同步到各大版本分支。
其中，黄色部分会反复进行，直到测试成功
1.1 从最开始只有 master，之后各 collaborators 开发新功能就需创建如 feature-1.0 分支，新功能开发完成后就合并到回master(只为保持主干最新，此合并应devops ci自动执行检查前置动作：代码编译、静态扫描、单元测试、代码审核、端到端测试等)。
1.2 开发完成即将发布新版时，就需基于 master 新建 release-1.0 分支（release 分支不是所有人都有 write 权限，committers 才有），然后触发 devops 流水线直接拉 release-1.0 分支发布到测试，(测试可能不通过，developer 提交再发布会反复进行多次），待测试通过之后，就需新建 release-1.0/v1.0.0 tag (对应构建 image 版本号，方便运维期间问题回朔)，此时再触发发布到生产的流水线 (拉取 v1.0.0 tag)
1.3 接着1.2发布到生产稳定运行一段时间后，此时可能又会发现 bug，然后 developers 修复完提交到 release-1.0 (同理经过发布-测试反复多次)，待测试通过之后，此时再新建 release-1.0/v1.0.1 tag，再触发发布到生产的流水线(拉取此 release-1.0/v1.0.1 tag)