最近公司的業(yè)務(wù)正在發(fā)展蓖墅，參與的人也越來越多库倘。但人數(shù)的增加也伴隨著風(fēng)險(xiǎn)的提升，良莠不齊的人員配置论矾，會(huì)使得代碼質(zhì)量難以控制于樟。這個(gè)時(shí)候，就需要在代碼入庫之前拇囊，加上一道質(zhì)檢步驟迂曲，通過這個(gè)質(zhì)檢步驟，能夠有限地規(guī)避一些風(fēng)險(xiǎn)寥袭。
本文以 Git 作為說明路捧，其他 VCS 工具，原理也大致相同传黄。
實(shí)現(xiàn)代碼審查杰扫，現(xiàn)在大體有兩種方式，分別是 類 Gerrit 或者 類 GitHub/Gitlab膘掰，這篇文章主要介紹后者章姓。
類 Gerrit
Gerrit 是最容易實(shí)現(xiàn)代碼審查的一種方式，它在真正倉庫和開發(fā)者之間建立了一個(gè)審核區(qū)域识埋，所有進(jìn)入代碼倉庫的代碼凡伊，都必須先通過這個(gè)審核區(qū)域。
git push origin dev/v1.0
這是最普通的提交方式窒舟，但在 Gerrit 中就不可以系忙。
git push origin HEAD:refs/for/dev/v1.0
上面是正確的提交方式，注意到兩者的區(qū)別了嗎惠豺？多了一個(gè) refs/for银还，這就是 Gerrit 的審核區(qū)域，只有通過審核洁墙，才能進(jìn)入主倉庫蛹疯。這里給了一個(gè)內(nèi)部實(shí)現(xiàn)圖，有興趣的同學(xué)可以參考热监，這里就不進(jìn)行額外介紹了捺弦。
類 Gitlab/Github
重點(diǎn)說說這類代碼審查如何展開，因?yàn)楝F(xiàn)在公司使用的就是這種方案，而且 Gerrit 的顏值太低羹呵，哈哈骂际。
權(quán)限分組
首先需要對(duì)權(quán)限進(jìn)行分組疗琉，每個(gè)組的?擁有不同的權(quán)限冈欢，一般情況下分為 owner, master 和 developer。owner 擁有最高的權(quán)限盈简，master 次之凑耻。我們用的最多的權(quán)限組就是 master 和 developer。master 能夠在保護(hù)分支上直接 push柠贤，而 developer 就不能香浩。這樣通過權(quán)限的劃分，就能保證屬于 develop 這個(gè)組的人臼勉，?在沒有代碼審查的情況下不能將代碼入庫邻吭。
保護(hù)分支
在 Gitlab/Github 上有保護(hù)分支這個(gè)概念，當(dāng)一個(gè)分支屬于保護(hù)分支的時(shí)候宴霸，developer 是不能直接入代碼的囱晴。
我們所進(jìn)行的?工作，很多時(shí)候瓢谢，都是版本迭代開發(fā)畸写。因而會(huì)有分支去跟蹤當(dāng)前版本迭代。有一種比較好的劃分方式氓扛，是 master / dev/version? / features/version?枯芬。 master 保存著當(dāng)前最穩(wěn)當(dāng)?shù)拇a版本，而dev/version? 則是當(dāng)前開發(fā)版本的代碼采郎，features/version? 是這個(gè)版本代碼開發(fā)?feature的倉庫千所。
developer ?的權(quán)限只能在 features/version? 上進(jìn)行工作。?那么如何合并代碼?到 dev 分支了蒜埋？就只能通過提交 Merge Request真慢，審核通過后，?master 將代碼弄到 dev 分支上去理茎。
Merge Request
上圖就是提交 Merge ?Request 的界面黑界。開發(fā)者可以選擇自己所在的 features 分支，將相應(yīng)的 commit 提交申請(qǐng)到 dev 分支上皂林。master 會(huì)看到如下的界面朗鸠，該界面顯示?是否需要合并這個(gè) Request。
是不是很簡單础倍？更多信息可以查看官方文檔烛占，?還有這篇博客
文檔信息
- 版權(quán)聲明：自由轉(zhuǎn)載-非商用-非衍生-保持署名（創(chuàng)意共享3.0許可證）
- 發(fā)表日期：2017年8月31日
- 社交媒體：weibo.com/woaitqs
- Feed訂閱：www.woaitqs.cc/feed.xml
