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

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

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

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

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

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

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

拉請求模型

還有一種解決代碼審查工作流程問題的方案：那就是由于GitHub而變得流行起來的拉請求模型。

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

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

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

想了解更多IT資訊，請訪問中培偉業(yè)官網(wǎng)：中培偉業(yè)