背景
git代码分支管理是devops的一个重要组成部分。而现状是，各个业务线没有统一的代码分支管理规范，这样会降低研发效率和增加线上代码的风险。所以需要一个统一的代码管理以及配套的产物环境管理。
方案原则：
-
尽量减少分支数量，降低分支管理成本，减少代码分支操作的失误。
-
要满足日常开发的易操作性和灵活度。
-
充分利用CICD的自动化管理代码分支功能，提升代码管理的效率，减少手动处理的出错率。
-
项目之间的开发和部署类型有比较大的差异，需要区别对待。
跟现在业务线的现状，方案分为三类场景：
-
日常开发场景。针对的是迭代频率较高，多需求开发同时进行的情况。包括公有云产品研发场景和私有化长期研发场景。
-
私有化部署开发场景。这种情况是指工程师用产出物部署（jar包，docker,k8s等）去甲方部署业务线的产品，这用情况会涉及到较少的开发。
-
共创开发场景。有些代码仓是需要两个团体共同维护，这两个团队既需要共享代码，也需要隔离部分代码，因为有些代码有的团队不需要。
开发过程中分支的处理流程
采用了与 CICD 高度集成的方式，充分提升分支和环境的管理效率，减少程序员写git命令处理分支的次数。
分为日常开发和线上bug处理开发。
日常开发流程
原则上只有有三个主干分支、feature分支、测试环境发布分支（release/test）,生产环境发布分支（release/prod）。当然可以根据需要再增加分支， 比如预发环境分支，UAT环境分支等。
首先，第一步从 master 最新的tag版本创建 feature 分支, 代码开发工作就在这个分支完成。
这里的feature分支是指从需求功能分解的最小代码实现单元，最好是一个人来提交代码。在提交测试前，feature 分支需求完成单元测试和开发环境的测试。
第二步，当 feature 分支单元测试时就可以考虑在测试环境发布了，在 CICD 平台会有一个完成单元测试的 future 分支池子。在这个池子中可以根据需求选择每次发布的 future 分支集合，并把这个集合作为新的发布版本代码集合。这样可以灵活的控制发布内容。
把一个或多个 feature 分支合并到测试环境的 release 分支（对应图中的release/test 分支），这时候进入测试阶段，如果测试环境中判断哪个 feature 分支的代码有问题，对应的feature 分支代码修改后经过单元测试再合并到 release/test 分支，直到测试环境通过后，再把各个feature分支合并到生产环境的 release/prod 分支，然后通过 CICD 发布到生产环境。
第三步，发布成功后在 release/prod 分支合并到 master 分支并打上新的tag版本号。
在这个流程中, 需要 CICD 的配合使用，具体与 CICD 的配合流程在下面：
-
Feature 分支从 master 分支创建，由于创建时间不同会出现不同的 tag版本的 feature 分支。
-
CICD 平台提供了一个feature 发布集合的功能，可以把认为可以作为一个版本发布的 feature 分支集合放入一个发布集合，同时，CICD 会判断要进入这个发布集合的 feature 分支的tag是否低于 master 分支的tag， 如果低了就必须和当前的 master 分支合并。
-
发布集合的所有 feature 分支会按顺序和 release/test 分支合并，并处理错误信息。
-
release/test 分支的合并处理完成后，触发 CICD 流水线把代码部署在测试环境上，在测试环境完成测试，测试不过继续在 feature 分支改代码，循环这个流程。
-
release/test 分支的代码在测试环境完成测试后，把release/test 分支合并到 release/prod 分支。
-
release/prod 分支的代码通过 CICD 把代码部署在生产环境，产品经理和测试需要在生产环境测试。
-
当生产环境出现问题时， 把 master 分支 merge 到 release/prod 分支，重新不是生产环境，然后再修改 feature 分支上的代码，循环这个流程。
-
生产环境发布成功时，把 release/prod 分支合并到 master 分支，并打上新的 tag 版本号。
-
删除新版本对应的 feature 分支。
注意事项：
-
每次只能发布一个版本到生产环境，不可多个版本合并上线，有利于减少上线验证复杂度和出问题后根据tag回滚。
-
可以增加环境，比如增加一个预上线环境等，同时在 CICD 上做好代码分支与环境的对应关系。
优点
-
没有太多的分支，减少了分支管理成本。
-
利用通过 CICD 上的 feature 分支集合管理功能，实现了通过动态配置feature分支集合来管理发布版本。
-
在 feature 分支进入发布 feature 集合之前就要验证是否小于 master 的tag 版本，这样就避免了后期合并分支产生过多的代码不一致的问题。
-
release/prod 发布代码之前会检查 tag 版本是否小于 master 分支上的tag 版本，这样在最后一步能避免代码版本问题，这个检测可以通过 CICD 设定。
FixBug 开发流程
Bug 分为紧急和非紧急。
紧急bug
当有紧急的 bug 需要修复时，直接从 走下面的流程：
直接从 master 拉取 hotfix 分支，代码完成后，可以在测试环境测试一下，没问题就可以发布，如果遇到紧急情况而且能保证代码没问题，就直接发布到生产环境。
非紧急bug
对应非紧急的bug的上线。先从 master 拉取一个 bug 分支，然后再合并到 release/test, release/test 可能有正在测试版本,就和这个版本一起上线
