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

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

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

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

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

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

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

拉請求模型

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

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

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

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

想了解更多IT資訊，請訪問中培偉業官網：中培偉業