Gerrit代碼Review入門實戰

代碼審覈（Code Review）是軟件研發質量保障機制中很是重要的一環，但在實際項目執行過程當中，卻由於種種緣由被Delay甚至是忽略。在實踐中，給你們推薦一款免費、開放源代碼的代碼審查軟件Gerrit。

**一、Why Code Review
Code Review是什麼**
Code Review最直觀的解釋即看代碼。常規的作法爲本身看，有時代碼邏輯問題可能本身看不出來，須要找同事一塊兒看，在你們知識體系相對平均的狀況下可能須要花錢專門的公司幫助查看。
 
Code Review須要看哪些？對於剛入職場或者剛接觸到Coding的新人來講，代碼風格是比較重要的一塊。除此以外，編碼規範及代碼結構寫法，框架和工具的選型，具體項目的業務邏輯，安全隱患，性能問題等均可以經過review的方式發現。Code Review從前日後大體分爲結對編程，提交代碼後，測試以前，發版以前，發版以後等幾個階段，越日後，Code Review的效果越差，修復的成本也愈來愈高。
 
爲何必定要作入庫前Code Review
首先，代碼審查的最大的功用是純社會性的。若是你在編程，並且知道將會有同事檢查你的代碼，你編程態度就徹底不同了。你寫出的代碼將更加整潔，有更好的註釋和程序結構。
 
其次，偷懶是人的天性，從節約成本的角度考慮，你們通常會選擇在測試以前無限制的Delay Code Review。入庫前作Code Review即是成本和效果之間最佳平衡點，它能及時發現問題，進行修改後確保代碼質量。
 
最後，代碼審查能傳播知識。在不少開發團隊裏，常常每一個人負責一個核心模塊，每一個人都只關注本身的模塊。除非是同事的模塊影響了本身的程序，他們從不相互交流。這種狀況的後果是，每一個模塊只有一我的熟悉裏面的代碼。若是這我的休假或辭職了，其餘人則一籌莫展。經過代碼審查，至少會有兩我的熟悉這些程序——做者，以及審查者。審查者並不能像程序的做者同樣對程序十分了解，但至少他會熟悉程序的設計和架構，這是極其重要的。

二、Gerrit簡介
Gerrit是Google爲Android系統研發量身定製的一套免費開源的代碼審覈系統，它在傳統的源碼管理協做流程中強制性引入代碼審覈機制，經過人工代碼審覈和自動化代碼驗證過程，將不符合要求的代碼屏蔽在代碼庫以外，確保核心代碼多人校驗、多人互備和自動化構建覈驗。

Gerrit以前的系統架構

Gerrit以後的系統架構

經過Gerrit機制將代碼作分隔。
 
Gerrit適用性

幾乎任何須要正式發佈的項目都應當使用Gerrit來進行代碼審查，若是Team中有新人，必須使用Gerrit確保代碼質量。
 
Gerrit效果

總體上來講，個推使用的標準配置爲Gerrit+Jenkins+Sonar，整個系統搭建完成後獲得的效果爲：100% Code Style問題避免入庫，80% 設計問題避免入庫，40% 邏輯錯誤避免入庫，20% 安全隱患避免入庫，100% 人員互備。

三、Gerrit入門實戰
Gerrit部署和運行
JDK環境配置
java -jar gerrit-2.12.war init -d review_site

Gerrit人員角色配置
使用OpenID登陸，第一個登陸的用戶爲admin，建立dev賬號、review賬號和verify賬號，建立dev、review和verify用戶組並添加相應用戶，注意設置Username，代碼同步時須要用到。

建立第一個項目，配置權限管理
添加project，選擇 Inherit From All-Projects，固然也能夠自定義Parent Project。

添加Verified標籤支持，這裏修改All-Project 項目的project.config，全部繼承自All-Project的項目自動添加Verified 標籤，也可針對項目自定義是否verify。

建立用戶組

添加相關用戶權限

將代碼庫同步到本地（SSH/Http）
HTTP 方式:
HTTP Password 密碼在 帳戶 - ->> Settings -->> HTTP Password 處獲取。

SSH方式:
添加SSH Public Key。

Clone代碼到本地

commit-msg ,提供自動寫入change-Id 至git log內功能
提交第一個change

Gerrit上進行代碼審查，確認入庫
Verify:
工程裏面接入了jenkins自動verify，結果可在上圖紅框內展現verify結果。
review代碼，提交入庫。

本地代碼庫更新，獲取最新入庫代碼
代碼submit後經過git pull - - rebase 更新代碼。

Gerrit入門實戰-初級修補
若是全部代碼提交均被打回，能夠進行暴力回滾：git reset <commit>，接着從新提交Gerrit，再進行Gerrit審查入庫。

Gerrit入門實戰-高級修補
若是單個提交打回，則可交互式回滾：git rebase -i <commit>，修改指定commit點：git commit --amend，完成全部commit點處理：git rebase --continue，而後從新提交Gerrit，最後Gerrit審查入庫。

Rebase前

Rebase 後

rebase 在同一個點上修改，不會產生審覈點，多個commit點同時存在是尤爲有用。

Gerrit經驗談

第一，Git別名綁定，添加別名字段，經過git review master這樣簡單語法提交到master源端分支，能夠省去不少工做。修改系統目錄或者項目目下的.gitconfig 文件，添加

也可經過git config --global alias.review 命令修改

第二，工具只是一部分，更重要的是人與人當面的溝通交流，你們討論一個好的解決方案，才能更好的解決問題。沒有交流，工具也就失去了意義。
最後，關於review積壓問題，要避免提交積壓，代碼審覈過程要及時完成，避免 Code Review流於形式。

從個推實際使用效果看，Gerrit在覈心代碼質量控制、知識傳承、團隊培養等方面都具有很高的實用價值，推薦給廣大開發團隊用。