花這么大的力氣得到這樣的結(jié)果是否值得？我的觀察如下

。  Gerrit允許對(duì)敏感的代碼庫(kù)進(jìn)行細(xì)粒度的操作。變更可以在授權(quán)人審查之后入庫(kù)。

這是Gerrit最主要的優(yōu)勢(shì)。別連原因都不知道就莫名其妙地強(qiáng)制代碼審查。只有人人都參與其中，才會(huì)獲得明顯的效益。最好約定其他的非正式代碼審查方式而不是一個(gè)以力服人的系統(tǒng)。

。  如果Gerrit的替代方案完全不允許操作代碼庫(kù)或者只能是只讀操作，那還是用Gerrit吧。

企業(yè)的某些部門可能會(huì)對(duì)操作諸如基礎(chǔ)設(shè)施配置之類的東西過(guò)分緊張。通常是為了不正確的原因。經(jīng)常面臨的問(wèn)題并不是人們對(duì)你的代碼太感興趣了，而是正好相反。

有些時(shí)候，敏感的密碼被簽人到代碼里，這被當(dāng)作一個(gè)不允許操作代碼的理由。

好吧，如果它讓你很受傷，別這么于。解決那個(gè)導(dǎo)致密碼放在代碼庫(kù)里的問(wèn)題吧。

拉請(qǐng)求模型

還有一種解決代碼審查工作流程問(wèn)題的方案：那就是由于GitHub而變得流行起來(lái)的拉請(qǐng)求模型。

在這種模型里，除非是代碼庫(kù)所有者，推送是不被允許的。不過(guò)其他開(kāi)發(fā)者被允許fork代碼庫(kù)，然后在他們自己的fork里做變更。當(dāng)完成變更時(shí)，他們可以提交一個(gè)拉請(qǐng)求。代碼庫(kù)所有者可以審查這個(gè)請(qǐng)求并決定是否把變更合并到主代碼庫(kù)里。

這個(gè)模型很容易理解，許多開(kāi)發(fā)者都從GitHub上眾多的開(kāi)源項(xiàng)目中獲得了經(jīng)驗(yàn)。

在本地創(chuàng)建一個(gè)能夠處理拉請(qǐng)求模型的系統(tǒng)需要像GitHub或GitLab這樣的東西，我們接下來(lái)將會(huì)看到。

想了解更多IT資訊，請(qǐng)?jiān)L問(wèn)中培偉業(yè)官網(wǎng)：中培偉業(yè)