代碼檢視工具Gerrit的平常使用

1, Gerrit是什麼？

Gerrit實際上一個Git服務器，它爲在其服務器上託管的Git倉庫提供一系列權限控制，以及一個用來作Code Review是Web前臺頁面。固然，其主要功能就是用來作Code Review。

2, Gerrit用戶配置

• Email激活
  Gerrit帳戶的設置界面，點擊「Contact Information」進入Email Register頁面，輸入本身的郵箱帳戶（此郵箱須要與本身的Git配置一致）。能夠配置多個Email帳號。

Contact Information

• SSH key配置
  經過如下命令生成並讀取本機ssh key:

ssh-keygen -t rsa
cat ~/.ssh/id_rsa.pub

Copy key的內容，在Gerrit帳戶的設置頁面「SSH Public Key」中加入便可。

ssh-key

3, Gerrit平常使用

3.1 獲取代碼庫

登陸Gerrit後在Projects-->List, 選擇相應工程your_project，進入該工程的General界面。
選中「clone with commit-msg hook」和「SSH」:

git clone ssh://your_account@review.xxxxx.com:29418/your_project && scp -p -P 29418 your_account@review.xxxxx.com:hooks/commit-msg cic-android/.git/hooks/

拷貝以上命令在本身本地Git命令行窗口執行便可拉取庫代碼。

3.2 Gerrit工做流程

3.2.1 上傳一個commit

Gerrit相對Git提供了一個特有的命名空間「refs/for/」用來定義咱們的提交上傳到哪一個branch，且能夠用來區分咱們的commit是提交到Gerrit進行審覈仍是直接提交到Git倉庫，格式以下：

refs/for/<target-branch>

Push一個Commit到Gerrit:

$ git commit
$ git push origin HEAD:refs/for/master

直接Push一個commit到Git倉庫:(咱們默認配置成不容許)

$ git commit
$ git push origin HEAD:master

當咱們的commit Push到Gerrit等待review時，Gerrit會將此commit保存在一個名爲「refs/changes/xx/yy/zz」的一個暫存branch中。
其中zz爲這個commit的patch set號，yy是change號，xx是change號的後兩位。

例如咱們工程中的這個大明同窗的提交：

http://review.xxxxx.com:9090/#/c/545/

一共提交了9次patch，那麼第9個patch就保存在一個名爲「refs/changes/45/545/9」的branch中。

能夠經過Gerrit頁面中該commit右上角的Download按鈕驗證,好比說咱們選擇「Cherry Pick」, 命令以下：

git fetch ssh://your_account@review.xxxxx.com:29418/your_project refs/changes/45/545/9 && git cherry-pick FETCH_HEAD

在此，有必要說下幾個概念，以便理解：

• Change
  一個Change包含一個Change-Id，這個Id就是經過咱們拉取代碼庫的時候所拷貝的hooks（hooks/commit-msg）自動生成的。
  包含一個或多個Patch Set，以及諸如Owner，Project，Target branch,Comments等信息。

• Change-Id
  Change-Id是一串SHA-1字符串。有hooks自動生成在咱們的commit message下面：

Feature:Music play.
BugId:/
Description:Music play.

Change-Id: I3d087f04d9d94bfaa93b8609b988b300af537497

在一個project的每一個branch中Change Id是惟一的。

• Patch Set
  一個Patch Set就是一次commit，Gerrit會將其生成一個Branch暫存。Change中的每提交一個Patch Set表示這個Change的一個新的版本，自動覆蓋前一個Patch Set， 默認狀況下，僅最後一個Patch Set是有意義的。Code Review經過時，也僅僅是最後一個Patch Set會合併到指定的branch中。

我的Git工做原則一
** 永遠是基於遠程庫的最新代碼工做，儘可能每一步操做（特別是add/commit/push）都經過git pull --rebase獲取一下當前最新版本。**

根據以上原則，建議在將本地commit push到Gerrit以後，立馬reset掉，或者從新切換一個新的分支工做。

3.2.2 上傳一個新的patch set

當咱們的commit被reviewer打回來時，咱們可能須要修改並從新提交。
若是咱們的代碼在本地分支已經reset掉，能夠經過Gerrit頁面提供的Download方式獲取：

// fetch and checkout the change
// (checkout command copied from change screen)
$ git fetch ssh://your_account@review.xxxxx.com:29418/your_project refs/changes/45/545/9 && git checkout FETCH_HEAD

若是以前是經過切換分支方式工做的，能夠從新切換回包含此commit的分支而無需執行上述命令，而後能夠在此代碼基礎上進行修改，從新add，amend commit:

// rework the change
$ git add <path-of-reworked-file>
...

// amend commit
$ git commit --amend

// push patch set
$ git push origin HEAD:refs/for/master

3.2.3 添加Reviewers

在Change界面添加相關reviewers.能夠考慮使用自動添加reviewers的插件

3.2.4 提交Change

Change通常配置成只有在Code-Review +2 以及Verified +1 的狀況下才能夠Submit。

Submit時可能會有衝突，界面會提示「Cannot Merge」字樣，此時能夠先嚐試Gerrit頁面提供的Rebase功能作一次Rebase操做，若是提示衝突，則需在本地解決衝突後從新提交一個Patch Set到該Change上。

本地Rebase的一種流程:

// update the remote tracking branches
$ git fetch

// fetch and checkout the change
// (checkout command copied from change screen)
$ git fetch ssh://your_account@review.xxxxx.com:29418/your_project  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

3.3 多Feature並行開發

Code Review須要時間，開發人員能夠在此期間開發其餘feature，這就產生了多feature並行開發的狀態。

爲了保證減小衝突和依賴，每個feature都應該是在該feature本身的本地分支開發，且此分支是基於遠程分支（target branch）的當前HEAD的。 也就是基於遠程庫的最新代碼開發，而不該該依賴於code review中的某個、某些Change。

固然，若是必要，你也能夠基於一個正在code review的Change開發新的feature，這樣會產生依賴，能夠在Gerrit中該Change的頁面看到「Related Changes」。這就要求reviewer也須要關注這個依賴關係，調整review時序。

根據以往的使用經驗，強烈建議不要產生這種依賴，儘可能使每個Change提交都是無依賴的，避免Change的連環失敗致使各類解衝突的工做。

我的Git工做原則二
** 儘量保證每個Change的完整性以及獨立性，且越小越好。**

4, 進階功能

4.1 Web頁面代碼修改

Gerrit提供了直接在Web頁面修改咱們的patch代碼的功能，這對於咱們作一些小的問題修改（好比格式化問題，命名不對，多餘的空格等)很是方便。

Edit

點擊Edit後，該工具欄顯示以下：

toolbar

能夠在此對patch的文件進行修改，刪除等。
若是想對文件中的某處進行編輯，點擊進入該文件的review界面：

page_edit

點擊編輯按鈕，進入編輯模式，編輯完save：

save

會在Change頁面看到，點擊Publish Edit按鈕，Gerrit會自動幫你生成一個包含剛剛修改的patch。

publish

patch

4.2 草稿箱功能

Gerrit能夠做爲一個本身的Change草稿箱，咱們能夠將一些還未完成，或者還不想提交review的Change上傳至此處。一來能夠做爲一個備份，另外在多人互相協助完成同一個功能，或是本身在多臺電腦（家裏、辦公室）上處理未完成的工做。
不一樣於提交一個正式Change的「refs/for/」協議，提交一個Change到草稿箱的協議方式爲「refs/drafts/」,以下：

$ git commit
$ git push origin HEAD:refs/drafts/luckyair

在Gerrit頁面的Drafts欄：

draft

草稿箱中的Change也能夠很方便的轉換爲正式的Change，而無需從新用「refs/for/」來提交，點擊Publish按鈕轉換爲正式Change，也能夠在此刪除此草稿。

publish draft

做者：anly_jun 連接：https://www.jianshu.com/p/b77fd16894b6 來源：簡書 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。