DEVOPS持续交付体系下传统应用程序版本控制？

其实人工拉取版本耗费时间并不多，也不会出什么问题，中间的问题出在，同一个版本的被多个开发团队进行不同需求的开发。
笔者所在的团队也因为实际情况，采取这种开发方式。比如开发负责人拉取一个20220117的分支，然后A团队基于这个分支进行需求1、2、3的开发，B团队基于这个分支进行需求4、5、6的开发，那肯定会出现问题的。
应该这样，对分支进行科学管理，采用行业比较规范的方式，如下。
master主干：线上的版本：主干的代码不做开发，目的是保留现在线上的版本，如果现在线上的代码出现任何的BUG或紧急添加新功能，就从master拉下来一个分支master_alter，master_alter分支的代码修改或添加后，然后测试打包发布，发布后把这个分支master_alter合并到master；删除master_alter分支，这时master任然是线上的版本；
release分支：预发布的版本、正在测试的版本：新需求已经开发完成，9.30号上线，这段的时间就是测试和修改BUG，我们给这个分支起名字叫release_930，等release_930版本的代码发布上线后，把release分支合并到master主干上，把release分支删除；
dev分支：正在开发的版本：假如公司出了两个新的需求，要给现在的商城项目添加一个新的功能叫购物车，然后我的这个分支叫dev_spc，日常的开发工作就一直在这个dev_spc这个分支上面；还要给商城加上店铺功能，然后我旁边哥们的分支就叫dev_shops，旁边这哥们他日常的开发工作就一直在这个dev_shops这个分支上面；开发完成后从dev分支合并到release分支，发布后再合并到master主干；master主干的代码不做开发用，保留现在线上的版本代码；

除此之外，笔者还是重点提一下代码合并。
每次上线之前，必须要对代码进行合并，举个例子，如果有abc三个版本，主干是A，由于实际情况比较复杂，基本上不可能由工具进行合并，合并由技术经理负责，有c合并到b，再由b合并到a，然后将a合并到A，因此需要由技术经理进行合并编排，认为规定合并逻辑和顺序，然后由工具进行合并。
代码合并采取人工加工具的方式最为稳妥。