轉：Gerrit 學習

標籤：

轉載：http://www.scmeye.com/thread-1665-1-1.html

入門
Gerrit簡介
Gerrit是一個建立在Git版本控制系統之上，基於Web的代碼審查工具，但如果你已經閱讀過該指南，那麼你可能已經知道了。介紹的目的就是然你回答這個問題，Gerrit是適合我的工具嗎？它是否適合我團隊的工作流程。
Gerrit是什麼?
我假設，如果你正在讀這篇文章，並且你已經相信一般的程式碼檢閱的好處，但需要一些支援人員是它容易。程式碼檢閱，對不同的人意味著不同的事情。對於某些人，是一個一台投影機和整個團隊通過一行行代碼的正式會議。對於另外的人，是在代碼提交之前的瀏覽代碼。
Gerrit提供一個重量輕架構，每次提交被接受合入程式碼程式庫之前，對進行程式碼檢閱。變更上傳到Gerrit，但實際上並沒有成為該項目的一部分，直到他們已經評審和接受。在許多方面，這是簡單的工具，以支援提交的補丁被應用到程式碼程式庫之前，被該項目的成員評審過標準的開源過程。然而Gerrit進了一步使項目所有提交以確保真正接受之前所有的變更都被檢查變的簡單。因為Gerrit對於如閉源的商業開發的情況，所有使用者都是被信任提交者同樣是有用的。無論哪種方式，它仍然是可取的程式碼檢閱，以提高代碼的品質和可維護性。畢竟，如果只有一個人看過的代碼，當人離開後它可能是有點難來維護。
Gerri首先是一個臨時儲存地區，變更成為一個程式碼程式庫的一部分之前，可以被檢查。它也是這一評審進程的推動者，擷取變更的筆記和備忘來對變更進行討論。對於不能面對面交流的分布式團隊，這是特別有用的。即使位於同底協作小組有評審工具，作為一個選擇也是有益的，因為每次評審對於評審人員是很方便的。允許開發人員建立評審和解釋的變更，當他們的想法還很新鮮的時候。如果沒有這樣的工具，他們要麼需要打斷別人來評審代碼，或者切換內容來解釋變更，這時他們已經轉移到下一個任務了。
這也創造持久的談話記錄，用來回答不可避免的“我知道我們修改的原因”問題。

 

Gerrit的適用範圍
任何多成員團隊都具有某種形式的中心程式碼程式庫（或他們應該有）。Git可以理論上沒有這樣的中心庫，但在實踐中通常有一個中心庫。這伺服器充當了實際項目的權威副本。中心伺服器是允許大家擷取和上傳代碼，一般是構建伺服器和其他類似工具擷取源。
特性1：中心程式碼程式庫
Gerrit部署在這個中心庫上，並增加了一個額外的概念，儲存待定的變更。所有人仍然從權威的庫中擷取代碼，但是推送到待定變更位置來代替直接推送到權威庫中。當變更被評審和接受後，才允許提交到權威庫中作為項目被接受的一部分。
特性2：代替中心庫
像任何庫的受管理的解決方案一樣，Gerrit具有強大的存取控制模型。使用者甚至可以被授予許可權直接推入中心庫，完全繞過程式碼檢閱。Gerrit甚至可以沒有程式碼檢閱，只用於管理庫和存取控制。但一般只是更簡單和更安全通過評審過程，甚至允許使用者直接推送。

 

建立評審
一旦你完成修改並提交到本地，這就是時候推送修改到Gerrit上去評審啦。推送到Gerrit伺服器就完成了。因為我們直接從Gerrit複製到本地倉庫的源沒有重新定義remote地址。
$ <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/master1
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:2 
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分支。每一個分支都跟蹤有一個神奇推送的refs/for/<branch_name>，來建立評審。你會注意這個命令的輸出，正是我們要推送到的Gerrit伺服器的HTTP串連地址。我們正是在這個web地址上評審這次提交。我們開啟串連看看能看到什麼。

 

特性3：Gerrit程式碼檢閱螢幕
Gerrit程式碼檢閱的螢幕上就會有人來評審變更。這裡看不到太多，你可以看看你的變更的差異，添加一些注釋說明你做了什麼，為什麼，你甚至可以添加一組人評審變更。
評審者可以通過各種方式指導需要評審的變更。Gerrit擁有強悍搜尋功能，項目負責人（或其他任何人）找到需要評審的變更。使用者還可以通過搜尋運算式來設定Gerrit項目設定關注，這樣Gerrit會通知他們匹配的變化。

評審變更
評審者的生活始於評審螢幕上的代碼。可以有多種方式到達這裡，但由於某些原因，他們已經決定將評審這一變更。特別值得注意的是此螢幕上的兩個“Need”的行：
* Need Verified
* Need Code-Review
Gerrit預設的工作流程在變更被接受前有兩個檢查。Code-Review是人的看代碼，以確保它符合項目的方針，意圖等。Verify檢查的是實際代碼的編譯、通過單元測試等。Verify通常是由一個自動構建的伺服器完成，而不是一個人。有一個Gerrit Trigger Jenkins Plugin外掛程式對每一次上傳的變更自動構建，並更新相應的verify分數。重要注意的是，Gerrit中Code-Review和Verify的許可權是不同，允許這些任務分開。例如：自動的過程可以有Verify許可權，但是沒有Code-Review許可權。因為我們是程式碼檢閱者，需要評審代碼。要做到這一點，我們可以在Gerrit Web介面上選擇合適的方式查看代碼，或者完整的檔案或者兩邊差異的試圖。在下面的圖例中，我們選擇了兩邊差異的試圖方式。在這些試圖中，你可以通過雙擊要備忘的行上添加備忘（或單擊行號）。一旦發布這些備忘所有人都能查看，允許對變更討論。

 

特性4:兩邊補丁評審
程式碼檢閱者最終花了很多時間瀏覽這些畫面，查看和評論這些變更。為了使這個操作儘可能高效，Gerrit有大多數快速鍵操作(甚至有些操作只能通過熱鍵訪問)。在任何時候，你可以打’？’鍵關來查看鍵盤快速鍵。
特性5:Gerrit熱鍵協助
一旦我們檢查完變更，我們需要完成提交評審。我們可以在我們初始進入的變更螢幕上點擊Review 按鈕。這使我們能夠輸入一個程式碼檢閱標籤和訊息。

特性6:評審變更
評審人員選擇的標籤，決定了下一步會發生什麼。’+1’和’-1’只是一個意見，但是’+2’和’-2’是允許或阻塞變更。為了變更被接受，它必須有最少一個’+2’並沒有’-2’。 雖然這些數值，但是他們不能計算;兩個+1並不等同於+2。不管什麼標籤被選中，一旦” Publish Comments ”按鈕被點擊，封面資訊和檔案的任何意見所有都使用者可見。在這種情況下，變更不被接受，創作者需要返工。因此，讓我們的切換角色到我們開始創造者。

 

變更返工
只要我們設定了Change-Id commit-msg鉤子，在我們上傳的變化之前，重新工作是很容易。所有我們需要上傳返工的變更，推送另一個具有相同Change-ID提交。由於鉤子再我們最初的提交中添加了Change-ID，我們可以簡單的檢出和修改提交。然後以之前建立評審時同樣的方式推送到Gerrit上，如下。
$ <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)
To ssh://gerrithost:29418/RecipeBook.git
* [new branch]      HEAD -> refs/for/master
請注意這一次輸出略有不同。我們並沒有得到一個新的評審記錄，因為我們追加到了已存在的評審記錄上了。返工提交上傳完成，我們可以回到Gerrit介面查看我們的變更。

 

特性7:評審返工提交
如果你仔細觀察，你會發現這個變更有兩個patch set，一個最初提交和返工提交。而不是重複我們的操作，假設這次補丁被程式碼檢閱人員給了+2。
嘗試變更 
Gerrit的預設工作流程有兩種簽收機制，Code Review和Verify。Verify是指檢查實際工作的變更。這通常會檢查代碼編譯，單元測試合格及類似檢查。項目真的可以決定，他們要在這裡做的多或少。這也許沒什麼價值，這僅僅是Gerrit的預設工作流程，Verify檢查實際上可以被刪除或增加其他驗證。正如在Code Review部分中提到，Verify通常是一個自動化過程，使用Gerrit Trigger Jenkins Plugin外掛程式或類似。但有時代碼需要手動Verify，或者評審人員需要檢查一些實際工作內容或工作原理。這些都需要有人將變更取到他們的開發環境中。Gerrit讓這個過程變容易，通過顯示每一個變化作為一個git分支。因此，所有的評論人員需要做的是，從Gerrit擷取和檢出該分支，他們將擁有變化。
我們不需要把這想的太難，如果你看過前面的Gerrit Code Review螢幕螢幕，你會發現一個” download ”命令。我們擷取變更需要做的就是,是複製粘貼此命令，並運行它在我們的Gerrit檢出。
$ 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.
這麼簡單，現在我們的工作複本已經有這個變更了，一起玩。你可能感興趣 refspec數字意味著什麼。
•        第一個68是變更號模100的編號。這個初始數的唯一原因以減少在git倉庫內的任何給定的目錄的檔案數量。
•        第二個68是變更的完整編號。你會發這個編號在Gerrit評審螢幕的URL中。
•        2是本次變更內的patch-set數。在這個例子中，我們上傳了一些修正，所以我們希望是第二個補丁集而不是最初被拒絕的。

 

手動的Verify變更
為簡單起見，我們只是要手動Verify變更。Verify的人可以與Code review的人相同也可以是完全不同的人，這真的取決於項目的規模和工作內容。如果你已經有Verify許可權，然後當您單擊Gerrit Web介面的Review 按鈕，你會要求驗證得分。
特性8:Verify變更
跟Code review不同Verify檢驗沒有+2和-2，只有成功或者失敗，必須有一個+1才允許提交(並且不能有-1)。
Submit變更‘
你可能已經注意到，在驗證的螢幕中，有兩個按鈕提交比分，” Publish Comments”和” Publish and Submit”。 ” Publish and Submit”按鈕始終是可見的，但只滿足提交條件才可以生效(例如已經Verify和Code Review過了)。所以這是很方便來張貼評審評分，以及通過點擊一個按鈕提交變更。如果你這時候只選擇發布意見，然後分數將被儲存，但變更尚未被程式碼程式庫接受。在這種情況下，住螢幕上會有一個“Submit Patch Set X”按鈕。正如Code Review和Verify，可以通過不同的使用者做不同的操作，第三個提交操作可以通過另一組使用者控制。
啟用Publish and Submit 或者Submit Patch Set X 按鍵，將變更合入到主庫中，成為項目被接受的一部分。擷取git倉庫後，這個人會接受這種變化作為主分支的一部分。Fetch git倉庫後，會接受變更作為主分支的一部分。

 

•        預設工作流程
Android開源項目（AOSP）使用Gerrit是基於Web的代碼審查工具。下面的圖片是一個流程圖，詳細說明一個補丁被寫入後會發生什麼情況。雖然它可能會有點複雜，下面的步驟大部分是在Web應用程式上進行的。
對於如何安裝和使用Gerrit和git的完整說明，請參閱提交補丁頁面。

 

轉：Gerrit 學習