git rebase流與代碼審查？可能？

Question

，這是另一個混​​帳流問題.. :(

我知道了「標準」 git的變基流非常好：

• 開發人員創建一個跟蹤分支（說「featureA」）關閉上游分支（說「主」）
• 開發代碼，提交與底墊，碼拉，提交與底墊拉等
• 代碼完成，開發商南瓜提交和推動掌握

我遇到的問題是這個在與主合併之前沒有留下代碼審查的空間。審閱者只有在主服務器上才能看到更改，因此如果開發人員需要調整任何內容，則主服務器上會針對給定功能提交多個提交。理想情況下只有一個。

，我知道會解決這個問題，但都不理想

有幾個選項：

• 有開發商推特性分支到遙控器。與此相關的問題是，他們從主人重新啓動後，推動將不得不是推力，雖然可能安全這種情況下，我不想像往常一樣生意。
• 不要重新綁定功能分支的上游更改，將它們合併。有了這個，我不能擠壓功能分支，並將提交回推給主（右？）
• 使用gerrit/github。我必須猜測，有一種方法可以在純粹的git中實現這一點？

有沒有更好的方法？

Answer 1

有一些第三方工具允許更復雜的審查工作流程。我們目前正在評估基於Gerrit的工作流程。

一個可能的格里特工作流程看起來是這樣的：

• 開發人員提交到一個特性分支。完成後，他壓縮功能分支並將其重新綁定到當前主設備上。
• 代碼審查軟件禁止直接推入主分支，因此開發人員會將該功能（壓扁到一個提交）推入審查系統，以供審查。 Gerrit在審查完成後以透明的方式將每個審覈請求作爲一個獨立的分支進行處理（櫻桃選擇也是可行的，但不是默認的）。
• 如果發生變化而不是通行代碼審查，開發人員可以修改提交併重新提交到審查系統。如果多個（修改）提交屬於同一個特徵查看請求，軟件會重新識別。審查終於完成時，只有最新的提交被合併到實際的主分支中。
  當然，由於每個功能只有一次提交，因此無法追蹤開發人員在代碼審查期間執行的調整（但是，據我瞭解，這實際上是需要的）。然而，每次審查請求的歷史由Gerrit管理，所以沒有任何事情真的丟失。

我們仍在評估類似於此的工作流程，但尚未在生產中使用它。所以我無法對這種方法在真實世界中的實際運行情況做出任何聲明。但我的觀點是，如果你有興趣與Git的更爲複雜的審覈工作流程，格里特可能是值得一試。

Answer 2

與此工作流程的最大的問題是有壁球一個承諾。這是Gerrit的限制。 CodeCollaborator解決了這個問題，並允許多個提交，我們更喜歡。