背景
在《一种适用于大规模应用系统双模研发的GIT分支模型（上篇）》中重点介绍了一种适用于双模研发的全场景Git分支模型的组成、特点及使用方式，本部分重点介绍该分支模型在农业银行信贷管理系统群（C3）中的应用实践。
农业银行信贷管理系统群（C3）包含20多个子系统，多技术体系并用，多环境并存，多时点交付，数百名部门内外研发人员参与协同开发，新项目研发、存量系统优化、临时需求及紧急变更等多种变更类型并发进行，团队协作复杂、变更控制繁琐。为了能够提升版本管理的效率、保证版本变更的安全性并能有效解决复杂开发场景中的团队协作问题，我们将全场景分支模型在该系统内进行了推广实践，并根据系统与部门特点制定了配套的分支管理与规划的规范，在实践中取得了很好的应用效果。
作者：宋绍磊、葛江浩、王丽敏
供职于中国农业银行研发中心，从事信贷管理领域系统研发工作，致力于银行大型IT系统端到端全流程敏捷转型的研究与实践。
Git分支在提供极大的灵活性的同时，难免会存在分支管理混乱的问题，尤其是在大团队协作中，不规范的分支命名容易导致分支的查找与切换困难，甚至会导致代码误提到其他分支。基于此，我们结合该系统研发特点提出了适合跨团队协作的功能分支命名规范。功能分支命名构成如下：
“GIT库名称/研发团队简称_变更来源及编号_功能简称及工作项编号_拟投产时间”。
以下为分支名称示例：
“CMS_F/fd_xm2018189_mcl192659_20180809”的含义是前台的分支，归属于fd团队，项目编号为2018189，对应的研发功能为“mcl”，对应的功能编号为192659，投产日期为2018年8月9日。
在该系统中进行团队协作开发的过程中，由于瀑布型研发与迭代型研发并存，并且涉及到跨团队、跨项目的协作，在多场景并存的情况下，分支规划的粒度是一个要重点考虑与设计的关键点。为此我们在该系统全场景分支模型中制定了“以同时投产的最小独立功能点为分支规划的基本粒度”的分支粒度规划原则，同时投产是指能够在很大概率上确定开发的功能点能够在同一窗口投产，最小是指只要分支间没有依赖关系就可以拆分出一个单独的功能分支进行维护，独立是指单个分支能够正常的完成功能的开发、联调、测试，并且具备独立投产的能力。在此基本原则下规划的分支可以保证功能分支的最小变动性。
在该系统中进行团队协作开发的过程中，代码开发过程首先要经过Dev分支的共享开发，申请功能分支后将Dev分支的开发内容挑拣到功能分支，同时开发人员在代码管理过程中经常会用到历史版本的选取、为其他人员传递代码文件等操作。针对分支间经常存在代码依赖关系，我们提供了“整体摘取、局部挑选”（如下图所示）的方式来实现代码的快捷传递，整体摘取用于保证开发功能的完整性，即将分支A上的一个提交作为一个整体传递到分支B中，“局部摘取”用于特殊文件特殊版本的处理，即满足特殊的开发要求，所有的操作通过界面一键式完成，无需开发人员通过线下手工传递代码，提高了版本共享的效率与准确性。
图1 通过TortoiseGit实现了commit级与文件级代码的挑拣
在该系统双模研发场景中，瀑布型研发与迭代型研发经常并行，投产日期经常交替，投产功能点存在临时延期、拆分、合并等特殊场景，同时对于特定功能的特定阶段，经常需要经过多个专有的测试环境进行测试，在传统的代码管理方式中缺乏有效的代码管理方式导致代码管理混乱、代码一致性差，尤其是在多个测试环境长时间并行的情况下各个环境的代码差异巨大，“所测非所投”现象普遍存在，影响功能测试、其他临时测试的顺利开展，同时代码拆分、合并、撤销等操作工作量大、易发生错误。
针对双模研发场景中特殊难题，我们通过对长期分支、短期分支进行统一规划，制定分支合并过程中的单向传递规则，对投产分支实行窗口化管理，对测试分支实行定向拉取管理等一系列措施实现了分支的按需创建、按需合并与定期销毁，并通过规范的标签管理、注释管理实现了代码版本的清晰分类、定向追溯。功能分支的按需合并，增加了功能测试、投产发布的灵活性，提高了版本制作的效率，同时保证了不同测试环境版本的强一致性。
在该系统的协作研发过程中，随着研发时间的推进，本地会积累大量的代码历史记录，为了提升开发人员的代码对比及摘取效率，同时节约磁盘空间，我们提供了代码浅克隆的机制，具体操作参见图2所示Git命令。
图2 代码浅克隆操作
通过实践对比发现，开发人员本地的代码历史数据量减少极为明显，减少了本地无效分支与标签的克隆，简化了本地工作区的管理。
整个系统中存在数十个大的研发模块，众多模块的代码增加了开发人员本地的代码量，严重影响代码的开发与调试效率，为此我们为开发人员提供了稀疏检出（sparse checkout）的配置策略，可以实现本地工作区中部分代码目录、文件的按需显示或隐藏，可以在本地工作区把与自己无关的模块的代码进行隐藏，提高本地工程的编译、调试效率，具体操作如下：
（1）打开sparsecheckout功能
在本地工作区右键“Git Bash Here”，打开Git命令行窗口执行如图3所示命令：
图3 打开sparsecheckout功能
（2）配置.git/info/sparse-checkout文件
如图4内容所示创建并修改文件 .git/info/sparse-checkout，文件首行是指要显示所有文件，行前有“！”符号表示该目录隐藏，无“！”符号表示该目录显示，根据本模块开发需求进行修改配置即可。
图4 稀疏检出配置文件示例
（3）重新切换检出Git分支
如图5所示重新执行一次Git分支检出操作，稀疏检出的配置就会生效，可以看到本地工作区中被排除的文件或目录将会被隐藏。
图5 Git分支检出操作
通过稀疏检出的配置，某前台开发人员的本地的代码空间占用从900M减少到了300M，极大的节省了本地磁盘空间并提升了本地工程开发与调试的效率。
本文提出了一种适用于大规模应用系统双模研发的全场景Git分支模型，并在农业银行信贷管理系统群（C3）中开展了应用实践，充分验证了模型推广的可行性与交付产品的准确性。分支模型的结构、管理规范及在实践中总结的经验能够为同类型的大型项目提供有益的参考与借鉴，可以通过局部改造的方式为更多的项目提供分支管理服务。
任何分支模型都不是完美的，该分支模型也存在一定的缺点，如基于Dev分支的代码开发在及时共享代码的同时也会把不规范的代码暴露给其他开发人员，Dev分支与Master分支长期运行后也可能会导致代码不一致的情况发生等。综合整个分支模型的优缺点和适用场景来说，该分支模型可以有效解决瀑布与敏捷双模型项目中的代码管理问题，适合大团队的协作，能够有效地应对复杂多变的需求和开发场景。
DevOps+LIVE技术直播 之 大咖解读
《2018全球DevOps现状调查报告》
DORA 公司 （DevOps Research and Assessment，DevOps 研究与评估机构）从 2014 年起每年都会发布一份 DevOps 现状调查报告。在过去五年里，全球有超过30,000名专业技术人员参与了这项调查。2018年度的报告于8月底发布英文版，为了方便国内小伙伴阅读，由DevOpsDays中国社区联合多位行业专家、资深实践者进行了独家翻译，并成为有史以来首个得到官方授权的中文版本。
