引言：互联网企业进行代码的版本管理已有成熟的方案，但直接照搬到银行内部使用会有水土不服的问题，考虑到银行复杂的开发环境和监管要求，提出FCMM的版本管理设计，以适应各种版本管理工具和各种开发场景。
开源 （1）当收到各类改造需求时，从lb-pkg（定版分支）中获取指定版本的代码，通过checkout创建对应的开发分支；
（2）各开发分支开发完成，根据版本计划，基于lb-pkg（版本分支）的指定版本创建tb-test-sit（SIT测试分支），并将各开发分支内容合并（merge）进来；
（3）通过tb-pub-sit（SIT发布分支）将SIT的版本和环境信息合并起来，供一并编译并部署到SIT服务器上进行测试；
（4）基于lb-pkg（版本分支）的指定版本创建tb-test-uat（UAT测试分支），对于通过SIT的版本，从tb-test-sit发布到tb-test-uat（UAT测试分支）； （5）通过tb-pub-uat（UAT发布分支）将UAT的版本和环境信息合并起来，供一并编译并部署到UAT服务器上进行测试；
（6）通过UAT测试的版本，可以从tb-test-uat合并到lb-pkg（定版分支），标注版本号为上线日期，等待最终上线；
（7）通过tb-pub-prd（生产发布分支）将定版的版本和环境信息合并起来，供一并编译并部署到生产环境（上线）；
（8）对于已上线的代码，从lb-pkg（定版分支）合并到master版本，完成生产版本的同步更新。
4.2.流程基本原则流程最基本的原则是要保证所设立分支的最长提交流程，不允许跨流程节点跳跃提交的做法，基于该原则，大致有以下的流程要求：
（1）存在测试分支的情况下（tb-test-），开发分支（tb-req-、tb-feat-、tb-fix-）只允许合并到测试分支，不允许合并到版本分支（lb-pkg）和主版本（master）；
（2）测试分支（tb-test-）应按实际的测试环节进行合并，非第一个节点的测试分支不允许从开发分支合并版本（tb-req-、tb-feat-、tb-fix-）；
（3）版本分支（lb-pkg）只能从最后一个测试分支（tb-test-）合并版本；
（4）主版本（master）只能从版本分支（lb-pkg）合并版本；
（5）与环境相关的代码不允许放到非配置分支（lb-cfg-）上。
4.3.流程裁剪可根据实际项目的需要，对配置管理分支和流程进行裁剪，来调节风险控制与执行效率的平衡。可进行的裁剪情景说明如下：
（1）单人开发（最精简场景）：单人开发的情况一般没有并行代码提交的问题，可以只保留master和开发分支，直接在开发分支上进行测试，测试通过的代码直接从开发分支同步到master；
（2）无待投产的场景：如果开发模式不存在定版待投产的状态，可以取消版本分支（lb-pkg），直接使用master作为版本分支进行处理；
（3）无发布分支的场景：建议与环境相关的信息开发为外部可替换的配置文件方式，不要写入代码中，这样可以编译程序可以直接分别获取测试分支（tb-test-）或版本分支（lb-pkg）的代码部分直接编译，然后再获取配置分支（lb-cfg-）的配置文件替换到服务器部署上，无需增加发布分支（tb-pub-）；
（4）按需设置测试分支：测试分支数量可按实际需要设置，不一定要区分sit、uat等多个环境。
5.提交说明规范每次代码提交必须填写提交说明，以保证过程信息能完整、准确地体现代码变更过程，同时通过规范提交说明内容，也可在最终版本打包时能自动生成变更说明内容。FCMM要求的提交说明规范遵循AngularJS项目Git提交日志规范（链接 Body部分的格式是固定的，必须写成Thisreverts转载请注明：http://www.0431gb208.com/sjszjzl/806.html
