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代碼，都會包含這筆提交。