Gerrit 工作流程
面向 Gerrit 的工作流程最好用三个分支的集合和一个小故事来说明。
最新的工程师 Fritz 被分配了 TICKET-123 来添加一项功能。在使用 git pull 同步 master 分支后（她已经从 Gerrit 克隆了仓库），她开始了这个舞蹈：
- 她发出了：
git checkout -b TICKET-123开始她的工作 自己的开发分支（在上图中，标记为developer-branch 的 Branch）。 - 在她从事该项目时，她发布了很多小的提交。
- 这个项目花费的时间比她想象的要长，所以她发布了：
git sync从master拉取。虽然她必须进行合并，但她觉得现在合并总比以后合并好。 - 她将所有小提交压缩为一个提交。
- 她创建了 Gerrit 评论。
- 她去了 Gerrit 仪表板，发现了她的更改，但是，当她这样做时，Jenkins 验证系统发现她的代码中存在语法错误。好在团队中没有人能把这个变化拉到他们的代码库中。
- 她很快在她的开发分支上进行了修复，并使用
git commit --amend提交了它 - 重新运行 Gerrit review 命令，修补了她原来的评论。
- 她将团队的成员添加到审阅者列表中（松了一口气，因为 Jenkins 已经给了审阅 +1 验证）。Gerrit 向他们发送了所有电子邮件，但其中一位审阅者注意到她没有更新
README文件，并给该评价打了2分。 - 她更新了开发分支上的
README文件，并使用了另一个git commit --amend命令进行提交。 - 她再次重新运行 Gerrit review 命令，该命令将另一个 “补丁” 应用于审阅。
- 这一次，审阅者给审阅者打了 +2 分，更改通过 Gerrit 接口合并到
master分支。
现在，团队的每个成员，包括 Fritz，一旦从 master 拉取，就会得到这个变化。