最新Gerrit2.16.15版本⽤户指南-中⽂⽂档
这是为Gerrit最终⽤户准备的Gerrit指南。 它说明了标准的Gerrit⼯作流程以及指导⽤户可以根据个⼈喜好来设置并使⽤Gerrit。
为了更好地理解本指南，读者最好了解Git，并熟悉基本的git命令和⼯作流程。
什么是Gerrit
Gerrit是⼀个Git服务器，为托管的Git存储库提供访问控制，并提供Web前端进⾏代码审查。 代码审查是Gerrit的核⼼功能，但仍然是可选的，团队可以决定直接使⽤但不进⾏代码审查。
⼯具
Gerrit使⽤git协议。这意味着要使⽤Gerrit，您不需要安装任何Gerrit客户端，只要拥有常规的git客户端（例如git命令⾏或Eclipse中的EGit）就⾜够了。
提交更改是什么
仍然有⼀些Gerrit客户端⼯具，可以选择使⽤这些⼯具：
Mylyn Gerrit Connector：Mylyn集成的Gerrit
Gerrit IntelliJ插件：IntelliJ平台集成的Gerrit
mGerrit：Gerrit的Android客户端
Gertty：基于控制台界⾯的Gerrit
克隆Gerrit项⽬
克隆Gerrit项⽬的⽅法与使⽤git clone命令克隆任何其他git存储库的⽅法相同。
克隆Gerrit项⽬：
$ git clone ssh://gerrithost:29418/RecipeBook.git RecipeBook
Cloning
可以在Gerrit Web UI中的Projects> List> <project-name>> General下到克隆项⽬的URL。
译者注：上⾯的UI为旧的GWT UI路径，2.16.15默认为PolyGerrit UI，3.0以后只有新的PolyGerrit UI界⾯。新UI界⾯路径
为BROWSE> Repositories> <project-name>，打开后最上⽅即为克隆路径。
对于git操作，Gerrit⽀持SSH和HTTP/HTTPS协议。
注意
要使⽤SSH，您可能需要在Settings中配置SSH公钥。
代码审查⼯作流
使⽤Gerrit进⾏代码审查意味着先审查每个提交，然后再将其合⼊到代码库中。
代码修改者对代码的每⼀次commit在Gerrit中都作为⼀个change。 在Gerrit中，每个change都存储在暂存区域中，我们可以对暂存区中的代码进⾏检查和审核。只有当这部分代码审核通过并且点击submitt按钮后，它才会被合并到代码库中。
如果有关于change的反馈（其他reviewer对你提交的代码提出了修改意见），那么作者可以通过amend commit来修改代码并提交新的补丁集。 这样，每次提交的change就可以迭代地得到改进，并且仅在准备就绪时才将其应⽤于代码库中。
上传⼀个change
通过对Gerrit推送⼀次提交就完成了⼀个change的上传。（这是⼀个很重要的概念，后⾯的⼤部分论述都以change为操作对象） 必须将提交推送到使⽤⽬标分⽀名命名的引⽤分⽀：refs/for/<target-branch>。 神奇的refs/for/前缀使Gerrit可以区分这次提交是需要代码审核的提交，还是不⽤审核直接合⼊仓库的提交。
对于⽬标分⽀，只需指定短名称即可，例如master，但您也可以指定完全限定的分⽀名称，就像refs/heads/master这样。
需要审核的推送：
$ git commit
$ git push origin HEAD:refs/for/master
// this is the same as:
$ git commit
$ git push origin HEAD:refs/for/refs/heads/master
绕过审核的推送：
$ git commit
$ git push origin HEAD:master
// this is the same as:
$ git commit
$ git push origin HEAD:refs/heads/master
注意
如果推送到Gerrit失败，请查阅Gerrit⽂档以了解错误消息。
推送提交进⾏审查时，Gerrit将其存储在暂存区域中，该暂存区域是特殊refs/changes/名称空间中的⼀个分⽀。 更改参考的格式
为refs/changes/XX/YYYY/ZZ，其中YYYY是数字更改号，ZZ是补丁集编号，⽽XX是数字更改号的后两位，例如refs/changes/20/884120/1。使⽤Gerrit并不需要了解此引⽤的格式。
获取更新
$ git fetch gerrithost/myProject refs/changes/74/67374/2 &&git checkout FETCH_HEAD
注意：
可以从你的更新提交界⾯中直接下载命令复制fetch命令。
refs/for/前缀⽤于将Gerrit“推送到审核”概念映射到git协议。对于git客户端，似乎每次推送都转到同⼀个分⽀，例如refs/for/master，但实际上对于推送到此ref的每个提交，Gerrit都会在refs/changes/名称空间下创建⼀个新分⽀。此外，Gerrit还创建了⼀个开放的change。
change包括⼀个Change-Id，元数据（所有者，项⽬，⽬标分⽀等），⼀个或多个补丁集，注释和投票。⼀个补丁集是⼀次git
commit。change中的每个补丁集代表该change的新版本，并替换了先前的补丁集。仅最新的补丁集是相关的。这意味着change的所有失败迭代将永远不会应⽤于⽬标分⽀，⽽只会集成最后批准的补丁集。
对于Gerrit来说，Change-Id很重要，因为它知道为代码检查⽽推动的提交是否应该创建新的change，或者是否应该为现有change创建新的补丁集。
Change-Id是SHA-1，其前缀为⼤写字母I。在提交消息（最后⼀段）中将其指定为页脚：
Improve foo widget by attaching a bar.
We want a bar, because it improves the foo by providing more
wizbangery to the dowhatimeanery.
Bug: #42
Change-Id: Ic8aaa0728a43936cd4c6e1ed590e01ba8f0fbf5b
Signed-off-by: A. U. Thor <author@example>
如果将提交消息中具有Change-Id的提交推送进⾏审查，则Gerrit会检查该项⽬和⽬标分⽀是否已存在具有此Change-Id的change，如果是，则Gerrit会为此change创建⼀个新的补丁集 。 如果不是，则使⽤给定的Change-Id创建新的change。
如果将没有Change-Id的提交推送进⾏审查，则Gerrit会创建⼀个新change并为其⽣成⼀个Change-Id。 由于在这种情况下，Change-Id不包含在提交消息中，因此在上传新补丁集时必须⼿动插⼊它。在推⼊第⼀个补丁集时，⼤多数项⽬已经需要⼀个Change-Id。这样可以减少意外创建新change⽽不是上传新补丁集的风险。 如果没有Change-Id，则任何推送都会失败，因为提交消息页脚中缺少Change-Id。
修改并重新确定提交将保留Change-Id，以便在将其提交进⾏审阅时，新提交将⾃动成为现有更改的新补丁集。
推送⼀次新的补丁集：
$ git commit --amend
$ git push origin HEAD:refs/for/master
Change-Ids对于项⽬的分⽀是唯⼀的。例如，在不同分⽀中解决相同问题的提交应具有相同的Change-Id，如果将提交pick到另⼀个分⽀中，则提交会⾃动发⽣。这样，您可以使⽤Gerrit Web UI在所有分⽀中按Change-Id搜索，到你的修复代码。
可以通过按照Change-Id⽂档中的说明安装commit-msg钩⼦来⾃动创建Change-Id。
您可以将其复制到git模板⽬录中，⽽不是为每个git存储库⼿动安装commit-msg钩⼦。然后将其⾃动复制到每个新克隆的存储库中。
审查change
上传更改以供审核后，审阅者可以通过Gerrit Web UI进⾏检查。审阅者可以查看代码增量，并直接在代码块或代码⾏中进⾏注释。他们还可以发布摘要评论并在审核标签上投票。审阅⽤户UI的⽂档说明了进⾏代码审阅的步骤与操作。
有⼏个选项可控制应如何呈现补丁差异。 ⽤户可以在diff⾸选项中配置其⾸选项。
上传⼀个新的补丁集
如果有来⾃代码审查的反馈，并且应改进更改，则应上传带有重新编写的代码的新补丁集。
这可以通过修改最后⼀个补丁集的提交来完成。如果需要，可以通过使⽤change页⾯中的fetch命令从Gerrit中获取此提交。
重要的是，提交消息中包含应作为页脚更新的更改的Change-Id（最后⼀段）。 通常，提交消息已经包含正确的Change-Id，并且在修改提交时保留了Change-Id。
推送⼀次补丁集：
// fetch and checkout the change
// (checkout command copied from change screen)
$ git fetch gerrithost/myProject refs/changes/74/67374/2 &&git checkout FETCH_HEAD
// rework the change
$ git add <path-of-reworked-file>
...
// amend commit
$ git commit --amend
// push patch set
$ git push origin HEAD:refs/for/master
注意：永远不要修改已经属于中央分⽀的提交。
推送新补丁集将触发电⼦邮件通知审阅者。
并⾏开发多个功能
代码审查需要时间，提交更新的作者可以使⽤它来实现其他功能。
每个功能都应在其⾃⼰的本地功能分⽀中实现，该分⽀基于⽬标分⽀的当前HEAD。这样，就不必依赖其他尚未审核通过的change，并且可以独⽴查看和应⽤新功能。如果需要，也可以将新功能基于其他尚未审核通过的change。这将在Gerrit的change之间创建依赖关系，并且只有同时应⽤了所有change，才能应⽤每个change。change之间的依赖关系可以从change页⾯上的Related Changes选项卡中看到。
查看项⽬
要了解新的更改，您可以查看您感兴趣的项⽬。对于查看的项⽬，Gerrit在上传或修改change后会向您发送电⼦邮件进⾏通知。您可以决定要通知哪些事件，也可以使⽤更改搜索表达式来过滤通知。例如，'branch:master file:^.*\.txt$'将仅向master分⽀中涉及到"txt"⽂件的更改发送电⼦邮件通知。
通常，项⽬团队的成员查看他们⾃⼰的项⽬，然后选择他们感兴趣的更改进⾏审查。
项⽬所有者还可以在项⽬级别配置通知。
增加新的代码审核者
在change页⾯中，可以将审阅者明确添加到change中。然后，将通过电⼦邮件通知添加的审阅者进⾏审阅。
主要是，此功能⽤于请求对已知是修改后的代码⽅⾯的专家或所实现功能的涉众的特定⼈员进⾏审阅。通常，不需要显式地为每个更改添加审阅者，⽽是您需要依靠项⽬团队来监视他们的项⽬并根据重要性，兴趣，时间等来处理即将到来的更改。
还有⼀些插件可以⾃动添加评论者（例如，通过配置或基于git blame注释）。如果需要此功能，应与项⽬所有者和Gerrit管理员进⾏讨论。
仪表板
Gerrit⽀持多种查询运算符，可以根据不同的条件（例如，根据状态，更改所有者，投票等）来查询更改。
显⽰更改查询结果的页⾯的URL中包含了这次查询的条件。这意味着您可以在浏览器中为该URL添加书签以保存更改查询。这样，以后可以很容易地重新执⾏它。
⼏个变更查询也可以合并到仪表板中。仪表板是Gerrit中的⼀个页⾯，⽤于显⽰不同部分中的多个更改查询的结果，每个部分具有描述性标题。
My> Changes提供了默认的仪表板(新UI默认主页就是仪表板)。它可以显⽰已经完成的审核、需要进⾏的审核和最近关闭的change。
⽤户还可以定义⾃定义仪表板。可以在浏览器中为仪表板添加书签，以便以后可以重新执⾏。
还可以⾃定义My菜单，并向其中添加⾃定义查询或仪表板的菜单项。
仪表板对于定义⾃⼰的change视图⾮常有⽤，例如您可以为不同的项⽬集使⽤不同的仪表板。
注意：您可以使⽤limit和age查询运算符来限制仪表板查询结果。单击章节标题将执⾏不带limit和age运算符的更改查询，以便您可以检查整个结果集。
提交change
提交change意味着将当前补丁集的代码修改应⽤于⽬标分⽀。提交需要Submmit权限，并且可以通过单击submmit按钮在更改屏幕上完成。
为了能够提交change，必须⾸先通过在审阅标签上投票批准change。默认情况下，仅当change在每个审阅标签上具有最⾼值的投票⽽没有最低值（否决票）的投票时，才能提交更改。项⽬可以配置⾃定义标签和⾃定义提交规则，以控制更改何时可提交。
提交change时，如何将代码修改应⽤于⽬标分⽀，由可在项⽬级别配置的提交类型控制。
提交change可能会因冲突⽽失败。在这种情况下，您需要在本地重新设置change，解决冲突并将具有冲突解决⽅案的提交上传为新补丁集。
如果由于路径冲突⽽⽆法合并change，则会在更改屏幕上以红⾊粗体Cannot Merge标签突出显⽰该change。
变基change
在检查change时，⽬标分⽀的HEAD可能会更新。在这种情况下，change可以重新基于⽬标分⽀的新HEAD。如果没有冲突，则可以直接在change页⾯上进⾏变基，否则必须在本地完成。
在本地进⾏变基：
// update the remote tracking branches
$ git fetch
// fetch and checkout the change
/
/ (checkout command copied from change screen)
$ git fetch gerrithost/myProject refs/changes/74/67374/2 &&git checkout FETCH_HEAD
// do the rebase
$ git rebase origin/master
// resolve conflicts if needed and stage the conflict resolution
...
$ git add <path-of-file-with-conflicts-resolved>
// continue the rebase
$ git rebase --continue
// push the commit with the conflict resolution as new patch set
$ git push origin HEAD:refs/for/master
仅当存在Gerrit⽆法解决的冲突时，才需要进⾏⼿动变基。如果需要⼿动解决冲突，则还取决于为项⽬配置的提交类型。
通常，change不应⽆故变基，因为它会增加补丁集的数量并在发出通知时产⽣噪⾳。但是，如果对change进⾏了长时间审核，则可能需要不时重新设置其基准，以便审核者可以查看⽬标分⽀当前HEAD的增量。它还表明对这个change仍然有兴趣。
注意：切勿对已经是中央分⽀⼀部分的提交进⾏变基。
放弃/恢复change
有时，在代码检查期间发现change很不好，应该放弃。在这种情况下，可以放弃change，以使它不再出现在未完成的change列表中。
如果以后需要再次使⽤，可以恢复被放弃的change。
使⽤主题
change可以按主题分组。 这很有⽤，因为它使您可以使⽤主题搜索运算符轻松到相关的change。此外，在change页⾯上还会显⽰具有相同主题的change，以便您可以轻松地在它们之间导航。
通常实现同⼀个功能或⽤户需求的change按主题分组。
可以在change页⾯中为change分配主题。
也可以通过在引⽤名称后附加%topic=…或通过使⽤命令⾏标志--push-option（别名为-o，后⾯加上topic=…）来设置推送主题。
Gerrit可以配置为⼀次单击即可提交主题中的所有change，即使主题跨越多个项⽬也是如此。
通过push来设置主题：
$ git push origin HEAD:refs/for/master%topic=multi-master
// this is the same as:
$ git push origin HEAD:refs/heads/master -o topic=multi-master
使⽤hashtags
hashtags是与change相关联的⾃由格式字符串，类似社交媒体平台上的⽤户标签。 在Gerrit中，您可以使⽤UI的专⽤区域
将hashtags与change改明确关联。 它们不会从提交消息或注释中解析。
与主题类似，hashtags可⽤于将相关change分组在⼀起，并使⽤hashtag：运算符进⾏搜索。 与主题不同，change可以具有多
个hashtags，并且仅⽤于信息分组。 具有相同标签的更改不必⼀起提交。
仅在NoteDb下运⾏时，hashtags功能才可⽤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。