Gerrit簡單介紹

參考：Gerrit官方文檔

Gerrit是基於Git的版本控制系統的web版代碼評審工具。

What is Gerrit

代碼審查對不同的人意味着不同的東西。對一些人來說，這是一次與設計師或一個團隊一行一行過代碼的正式會議。對其他人來說，就是在提交代碼之前，讓別人瀏覽一下代碼。

Gerrit的目的就是爲代碼提交到代碼庫之前提供一個評審的輕量級框架。代碼提交到Gerrit上之後，實際上並沒有真正被項目接受，直到被評審通過。

Gerrit在代碼被正式接受之前，爲代碼檢查設置了一個staging area，在這裏可以對該提交進行修改、討論、增加註釋……

分佈式進行、不需要面對面操作。

Where does Gerrit fit in?

任何一個團隊都有某種類型的中央代碼庫。Git理論上可以在沒有中央代碼庫的情況下工作，但實際上他有一箇中央存儲庫。這是項目中實際存在的權威性副本。每個人或編譯服務器都可以從中央的認證代碼服務器下代碼或推代碼。

Gerrit也是部署在中央代碼倉庫的地方，只是增加了新的部分，一個staging area。每個人仍然可以從代碼庫中下載代碼，但是並沒有直接推送回去。修改暫時推送到Gerrit提供的staging area，只有最終通過評審，才能提交到中央代碼庫中。

同時Gerrit具有強大的訪問權限控制，用戶可以被賦予繞過代碼評審的權限直接推送代碼。Gerrit也可以僅用作代碼存儲，不進行代碼評審。

The Life and Times of a Change

瞭解Gerrit的工作原理的最簡單的方法就是熟悉一個change的生命週期。我們假設，Gerrit 服務器（gerrithost）使用http的8080端口、ssh的29418端口，並且所有的開發都在RecipeBook這個代碼庫的master分支上進行。

Cloning the Repository

首先，使用git clone的方法，從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代碼的地址。

這就是我們的代碼評審頁面，這裏可以看到提交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”），或者單擊行號列標題中的圖標來添加文件註釋。一旦發佈這些註釋，所有人都可以看到，允許進行更改的討論。

因爲評審代碼（查看、評論、修改～）會花費很長時間，所以Gerrit提供了一些快捷鍵，來提高效率。

當我們查看完代碼之後，我們需要添加我們的評審意見。點擊頁面上的“Review”按鈕，就可以添加我們評審意見並打分。

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。

這時，這個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“可以和”Reviewer“是同一個或不同人，有權限verify的人，可以點開”Review“按鈕進行驗證打分。

"verify"沒有+2或-2選項，所以我們只能對提交的change進行+1或-1的操作。

Submitting the Change

當change被verify+1和code review +2了，這時頁面上會出現"submit"按鈕，點擊這個按鈕，就可以把這個change正式提交到代碼庫中。這時，再添加新的comment，不會修改打分；而如果上傳了新的patch，打分就會重置。

和“verify”、“code review”一樣，“submit”的權限也是也是掌握在一組人手中的。

當代碼被submit之後，任何人從代碼庫中git clone代碼，都會包含這筆提交。