Gerrit brief

Reference: Gerrit official documents

Gerrit code review tool is web-based version of the version control system Git is.

What is Gerrit

Code review means different things to different people. For some people, this is a formal meeting with the designer or a team of line by line through the code. For others, that is, before submitting the code, let others look at the code.

Gerrit aim is to submit the code to provide a review of the code base before the lightweight framework. After the code is submitted to the Gerrit, in fact, it is not really accepted the project, until approval.

Gerrit before the code was officially accepted, set up a staging area for the code checks, where you can modify the submission, discussion, add comments ......

They were distributed, no face to face operations.

Where does Gerrit fit in?

Any team has some type of central code base. Git is theoretically possible to work without a central code base case, but in fact he has a central repository. This is the authoritative copy of the project actually exists. Each person or server can compile the code from the central server or authentication code push code.

Figure 1. Central Source Repository

Gerrit is also deployed in the local central code repository, just added a new section, a staging area. Everyone can still download the code from the code base, but did not directly push back. Modify temporarily pushed to the staging area Gerrit provided only by the final assessment, in order to submit to the central code base.

Figure 2. Gerrit in place of Central Repository

Powerful access while Gerrit has control, users can be given permission to bypass the code review of Direct Push code. Gerrit may be used only as a code memory, does not code review.

The Life and Times of a Change

Learn how Gerrit's the easiest way is to change the life of a familiar cycle. We assume, Gerrit server (gerrithost) using the http port 29418 8080 port, ssh, and all development is done on the master branch RecipeBook this code base.

Cloning the Repository

First, git clone method, we have to get modified source code from gerrithost

$ git clone ssh://gerrithost:29418/RecipeBook.git RecipeBook
Cloning into RecipeBook...

然后我们就可以在本地进行实际的修改和提交。Gerrit通过hook在commit message中加了一个Change-Id,这样就可以关联这笔提交的不同版本。

Creating the Review

当本地进行了修改并且commit之后,就可以把代码push到Gerrit上进行review了。

$ <work>
$ git commit
[master 9651f22] Change to a proper, yeast based pizza dough.
 1 files changed, 3 insertions(+), 2 deletions(-)
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 542 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote:
remote: New Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master

唯一的不同点就是refs/for/master分支,我们是主要是通过这个分支,对提交到master分支的代码就行review。

git push之后的返回值,有个http的链接,这个了解就是我们提交review代码的地址。

Figure 3. Gerrit Code Review Screen

这就是我们的代码评审页面,这里可以看到提交change的差异、添加评论说明做了什么和为什么这么做。

评审人可以设置多种搜索条件,来查询他们关注的change;并且可以对gerrit 的project设置一定条件的监听(watch),这样当有他关注的修改出现时,会有邮件提醒。

Reviewing the Change

当评审人(Reviewer)来到评审页面,当页面中有如下字样时,便可以进行评审。

* Need Verified
* Need Code-Review

在代码被accept前,Gerrit有两条检查的工作流要求。“Code-Review”表示一个人觉得这个修改满足项目要求;“Verifying”表示这个修改通过了编译、单元测试……。“Verifying”通常由自动化构建服务器实现,比如jenkins的gerrit trigger插件就可以进行verify并打分。

“Verified”和“Code-Review”在Gerrit中需要不同的权限,所以任务需要分开。

作为Reviewer,我们可以通过双击要注释的行(或单击行号)来添加inline comments。此外,还可以在标题中双击任何地方(不仅仅是“patch set”),或者单击行号列标题中的图标来添加文件注释。一旦发布这些注释,所有人都可以看到,允许进行更改的讨论。

Figure 4. Side By Side Patch View

因为评审代码(查看、评论、修改~)会花费很长时间,所以Gerrit提供了一些快捷键,来提高效率。

Figure 5. Gerrit Hot Key Help

当我们查看完代码之后,我们需要添加我们的评审意见。点击页面上的“Review”按钮,就可以添加我们评审意见并打分。

Figure 6. Reviewing the Change

Reviewer的评审一件决定了这个change的走向。“+1”和“-1”只是一种一件,“+2”和“-2”表示这个change是被accept还是block。要想这个change被accept,必须有一个“+2”而不能有“-2”。数值不会累加。

不论选择了哪种标签,一旦点击了“Publish Comments”按钮,所有的信息都能被用户看到。

如果Change没有被accept,那么开发就需要重做(rework)了。

Reworking the Change

如果在最初push之前,我们设置了“Change-Id commit-msg hook”,那么重做(rework)就比较简单了。如果两个change有同样的Change-Id,重做后的change,就可以直接push到那一个上面。E.g.

$ <checkout first commit>
$ <rework>
$ git commit --amend
$ git push origin HEAD:refs/for/master
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 546 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: Processing changes: updated: 1, done
remote:
remote: Updated Changes:
remote:   http://gerrithost:8080/68
remote:
To ssh://gerrithost:29418/RecipeBook.git
 * [new branch]      HEAD -> refs/for/master

push之后我们得到的输出和上次不同,是“Updated Changes”,它告诉我们现有的review已经更新了。

打开回传的http链接,查看已经更新的change。

Figure 7. Reviewing the Rework

这时,这个change下面就多了一个patch set。

Trying out the Change

有时代码需要手动验证,或者reviewer需要检查代码实际的工作方式。这时我们需要把change download到本地来进行验证。gerrit 提供了download command的插件,在gerrit的页面中也有download的命令可以直接复制。

$ git fetch http://gerrithost:8080/p/RecipeBook refs/changes/68/68/2
From http://gerrithost:8080/p/RecipeBook
 * branch            refs/changes/68/68/2 -> FETCH_HEAD
$ git checkout FETCH_HEAD
Note: checking out 'FETCH_HEAD'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at d5dacdb... Change to a proper, yeast based pizza dough.

说明:

  • 前一个68,是change的id mod 100的值,为了减少git库内指定目录的文件数量
  • 第二个68,这个change的真实id,就是屏幕上的返回值。
  • 2,就是patch set的id,因为第一条被拒了,所以要的是第2个。

Manually Verifying the Change

"Verifier" and can "Reviewer" are the same or different people, who have permission to verify, you can point to open the "Review" button to verify the scoring.

Figure 8. Verifying the Change

"Verify" no +2 or -2 option, so we can only change submitted by +1 or -1 operation.

Submitting the Change

When the change is verify + 1 and code review +2, and then there will be "submit" button on the page, click on this button, you can put this change officially submitted to the code base. Then, add a new comment, does not modify the scoring; and if uploading a new patch, scoring will be reset.

And "verify", "code review" Like, "submit" permission is also rests in the hands of a group of people.

When the code is submit, any person from the code repository git clone code will include this submission.

Guess you like

Origin blog.51cto.com/muyusen/2438406
Recommended