Gerrit，一种开放源代码的代码审查软件，使用网页界面。利用网页浏览器，同一个团队的软件开发者，可以相互审阅彼此修改后的代码，决定是否能够提交，回退或是继续修改。它使用版本控制系统Git作为底层。
1. 常规开发流程
多开发人员相互协作，各种特性分支开发，最终提交至中心仓库
2. 常规Git分支管控
2.1. 标准的GitFlow流程
2.2. GitFlow简要说明
- Master分支：作为集成分支，包含最新功能特性；
- Develop分支：将Feature作为功能集成分支
- Feature分支：开发人员关注的分支，负责单独的需求功能研发使用
- Release分支：作为预发布分支
- 发布之前，通过Develop分支拉取而来
- 包含版本ToDo特性功能（提前做的版本规划）
- Release需要有发布规划v1,v2,v3….
- Tag签发，针对测试通过的分支进行预发布 & 生产
- Release特性同步回到Master和Develop分支
- 代码回滚（由发布系统记录和完成）或复盘点
- HotFix分支：针对线上生产环境的分支，拉取HotFix分支，进行补丁修复，修复后，需要同步至Master和Develop
2.3. 针对GitFlow流程补充
针对Git的使用流程，不同的企业有不同的管控方式，这里补充两类：
- PlanFlow：时效性低，发布计划性强，每个Release有确定的Todo清单，方便测试统一验证，适合有项目管理与功能ToDo清单的团队，可以废弃掉了Develop分支，降低分支维护成本，关注Release分支的版本特性清单
- Master(功能集成用)，保证最新特性
- ReleaseN(并行给到多开发者，N代表并行的数)，每个ReleaseN有自己的版本Todo清单，开发完成后，将ReleaseN合并到Master
- Tag基于Master，发布基于Tag发布
- HotFix基于Master
- GitFlow：时效性效率高，依赖开发人员的水平，适合敏捷型开发团队；另外，若没有自动化测试，由于高频发布，需要有CI/CD以及自动化测试的辅助，否则容易导致生产故障。由于提交、合并、发布持续进行（CI)，适合功能快速集成，支持研发功能后，随时发布（同时也伴随的代码质量、缺乏严格测试导致生成问题的风险）
- 加入有发布版本规划，每个Release有自己的ToDo项目规划
- 开发完的Feature可以及时合并到Devlop
长期来看，若CI/CD以及自动化测试这块功能跟上，这样可以大大提升功能上线的时效性，让某个特定的功能及早面向用户！
3. 加入Gerrit代码审核流
3.1. Gerrit图示概览
用户过往直接push到代码仓库，需要先提交到Gerrit的远程分支，然后代码审核人员审核后，Gerrit会自动将代码合并中心仓库，然后在CD集成。
- 提交者不能直接把代码推到远程的master主线(或者其他远程分支)上去（相当于越过了gerrit了），gerrit必须依赖于一个refs/for/*的分支。
- 当进行commit时，必须要生成一个Change-Id，否则gerrit会报错。
普通成员的代码是被先push到gerrit服务器上，然后由代码审核人员，就是左上角的integrator在web页面进行代码的审核(review)，可以单人审核，也可以邀请其他成员一同审核，当代码审核通过(approve)之后，这次代码才会被提交(submit)到代码仓库(repo)中去。
无论有新的代码提交待审核，代码审核通过或被拒绝，代码提交者(Contributor)和所有的相关代码审核人员(Integrator)都会收到邮件提醒。
gerrit还有自动测试的功能，和主线有冲突或者测试不通过的代码，是会被直接拒绝掉的，可以基于Jenkins实现该目的。
3.2. Gerrit代码审核流
主要关联对象：开发人员、代码审核人员、Gerrit在线审核、Jenkens自动化分支合并
