坩堝與Gerrit相比？

我們現在正在使用Atlassian的Crucible來進行代碼評論（我們並沒有真正使用FishEye部分），並且它開始變得無法使用，主要是因爲performance issues將索引大型回購和多個回購。坩堝與Gerrit相比？

我們的代碼託管在Github上，我們鼓勵開發人員分叉回購，並在他們自己的分支中完成所有工作。爲了與Crucible一起工作，我們需要索引所有開發者分支。我們已經開始這樣做了，但需要很長的時間（每次提交的小時數）。請參閱上面的鏈接。

Gerrit如何比較？它是否索引回購？

我知道人們會評論說，Github已經提出了對代碼評論的請求（我們使用它們），但是一旦評審結束，請求確實在工作流程結束時完成。我們有一個由20人組成的開發團隊，而且Github中沒有一個系統可以管理哪些開發人員需要完成哪些評論/拉取請求。另外，JIRA整合的坩堝很不錯，我們利用這一點。

我也接受其他代碼審查工具，而不僅僅是Gerrit。

來源

2011-11-23 Valdis R

只是想指出，你並不總是要等到最後才提交一個pull請求。 GitHub寫了一篇關於他們如何使用它們的文章，並且他們提前創建了請求：https：//github.com/blog/1124-how-we-use-pull-requests-to-build-github。儘管如此，仍然無法解決其他問題。 – jszakmeister

最後，我們決定簡單地使用Pull Requests;合併請求打開，然後我們的票務系統用合併請求URL更新。直到質量檢查員驗證了這些更改，然後它們合併爲止，它纔會合併。 –

我已經開始在工作中使用Gerrit（6人小組，內部沒有Github）。它不需要「索引」任何東西，但Gerrit更喜歡堅持「主」存儲庫。所以一個新的開發人員會直接克隆Gerrit。

開發人員所做的更改被推送到Gerrit的特殊參考資料上，該資源創建了一個審閱對象。其他開發人員可以根據需要專門提取該評論的提交，但默認情況下，提交在正常分支上不可用，直到審閱通過。

Gerrit可以設置各種各樣的權限選項，這些選項需要一些習慣。如果需要，您可以配置哪些用戶可以按每個分支執行哪些操作。我們有一個大的存儲庫（20年以上的代碼庫），但只有大約2年的提交歷史（從以前的VCS遷移過來）。沒有性能問題，並且由於Gerrit的工作方式，我不指望隨着存儲庫的增長。

[我沒有用坩堝。]

來源

2011-11-23 18:05:59

您的標準工作流程是否包含主題/功能分支？我們喜歡保持主（基本上）可釋放，所以所有的錯誤和增強進入不同的分支。 –

是的，所有開發都是在分支上完成的（並在分支上進行審查），然後再將另一個分支合併到主分支中。合併步驟也通過Gerrit進行，因此將功能添加到主設備中可以與功能本身的開發分開進行批准。當前版本的Gerrit並未很好地處理合並提交的審查，但請參閱http://code.google.com/p/gerrit/issues/detail?id=665以獲取更多信息。 –

你實際上並不必須有獨立的叉子發出引入請求，就可以讓每個人都需要具有一個回購協議，推動功能轉移到GitHub上，然後單擊在'拉'請求'從'功能1'到'主''

來源

2011-11-23 22:39:09

沒錯，我知道，但有一個單獨的叉子來表明所有權的功能以及確保我們不會在主要的回購庫中出現一堆孤兒分支。 –

像格雷格說的，Gerrit認爲它擁有存儲庫，並沒有一個好的方法（目前）與github結合使用它。你可以把它連接起來，這樣一旦代碼在gerrit中被檢查/驗證/合併，它就會被推送到github，開發者仍然可以從那裏獲取。

我不相信您會遇到任何性能問題 - Gerrit被Google和其他大公司內部的大多數Android商店和其他地方使用。數以百計的開發人員涌向成千上萬的存儲庫並不罕見。

如果您目前在github上託管，您將需要提供自己的硬件，這需要稍微強健。 Gerrit會很樂意使用所有你可以給它的內存......我相信有些地方使用64GB或更多內存，但是$ DAYJOB可以爲幾百個開發人員提供16GB左右的空間。

主題分支在Gerrit上工作得很好，並且一直在變得越來越好。

Gerrit並不能真正解決您指定開發人員自行完成審閱/驗證/合併的問題。開發人員可以將其他開發人員添加爲更改/提交的審閱者，但是沒有官方的工作流程/所有者概念。我的團隊使用Jira - 一旦完成任務，將Jira問題分配給某人進行審查，然後將其分配給某人進行驗證等等。此處還有許多其他選項。

我懷疑Gerrit會很好地滿足您的需求。我建議你試試看！

來源

2011-11-24 03:00:24 Brad

另一種選擇可能是ReviewBoard，它主要適用於git。在之前的工作中，我編寫了一個腳本，該腳本使用post-receive鉤子來在每次將內容推送到中央存儲庫時自動創建評論。 ReviewBoard並不像Crucible或Gerrit那麼漂亮，但我們從Crucible轉到了它，原因正是你描述的原因。

ReviewBoard和git的一些小問題主要涉及一些古怪的情況，比如試圖回顧自回購開始以來的每一次提交 - 我發現通常在這種情況下，我必須自己格式化並上傳它，而不是讓它ReviewBoard的postreview.py腳本處理它。

請注意，很少的代碼審查工具實際上是按照Crucible所做的方式對存儲庫進行索引。他們中的大多數都依賴於補丁，無論是由像postreview.py這樣的工具自動生成，還是通過查看提交併在內部生成diff。

來源

2011-11-24 05:41:49 ebneter

Gerrit？漂亮？ *困惑的笑* – SyntaxRules

坩堝與Gerrit相比？

回答

相關問題