我正在尋找建議/經驗/最佳實踐，瞭解如何讓一個開發團隊儘早承諾提交工作範例，同時仍能從全面的代碼審查流程中受益。我們目前使用審查委員會，並且政策規定不要將代碼提交給沒有同行評審的SCM。雖然我完全接受代碼審查，但它似乎會減緩整個流程，並且會對提交早期提交的常見想法產生巨大的阻礙。所以我在尋求其他方面的經驗。你是否經常提早做出承諾？你是否也使用代碼評論？有沒有一種明顯的方式（我錯過了）這兩個想法可以融合在一起？通過代碼評論提交提前通訊？
我建議也許切換到分佈式SCM。你可以這樣做，讓團隊中的每個成員都承諾自己的存儲庫。當某個功能準備好進行審閱時，審閱者會收到通知。如果審閱者接受這些更改，他會將它們壓入/合併到穩定的存儲庫中（這非常容易）。
Git和水銀（汞）是分佈式SCM的
首先，你使用的是什麼版本控制軟件很好的例子？
根據您的RCS軟件，您可以同時實現兩個目標。例如，如果您使用的是Subversion，每個開發人員都可以提前並經常提交給他們自己的私人開發分支。在任何開發分支合併到主幹之前，可能需要同行評審。其他RCS系統很可能做類似的事情。
編輯：我忘了提，如果你確實使用了「承諾早，經常」使用Subversion（有或沒有開發分支）的策略，開發人員需要確保他們update他們的工作副本與變化一如既往地致力於幹線。在我們從VSS遷移到Subversion之後，這是我的團隊一段時間的問題。我們不習慣能夠進行三向合併，開發人員不經常更新他們的工作副本（有時每天不到兩次），這通常需要大量的手動合併。最終，無論何時提交提交（我們有一個提交後鉤子，用新提交更新RSS提要），或者至少每隔一小時左右，每個人都習慣於運行svn update。因此，大部分合並都是自動處理的，將開發分支的變更合併到主幹中所需的手工工作量通常是微不足道的。這也使得trunk和開發分支之間的diff儘可能小，這使得代碼檢查更容易（因爲我們通常關注分支和主幹之間的diff）。
我認爲SCM是比RCS更常見的縮寫。而且，顛覆並不是真的因爲它容易合併而聞名。這種私有/公共存儲庫設置註定會失敗。分佈式SCM是用於這種方法的。 – 2010-07-07 15:22:37
也爲這種方法分支。 – stannius 2010-07-07 15:26:36
@Peter Smit-僅僅因爲它不容易並不意味着它註定要失敗。現在我的團隊已經成功完成了一段時間。我避免推薦分佈式系統，因爲考慮到OP的現狀（您知道有多少管理層喜歡重大更改），聽起來像是在一個步驟中做出了太大改變。你可以從SVN開始，然後開發人員開始使用git-svn來提高生產力等等。一次一個步驟。 – bta 2010-07-07 15:28:59
使用分佈式版本控制系統。集中版本控制的最大缺點之一是阻礙了「提前提交，經常提交」。分佈式系統鼓勵它。
我不想辯論集中版本控制是否「阻礙」了這種技術，但它肯定不能阻止這種技術。我一直致力於早期版本控制工具，並經常使用超過20年的集中式版本控制系統（除了必須使用Visual SourceSafe的黑暗年份以外）。 – Oddthinking 2010-07-07 15:32:16
當您沒有提交時經常提交（共享）主要分支與持續集成的關係 – ianpojman 2012-06-29 19:25:33
所有現有的答案都提出了分佈式SCM。這是足夠的，但不是必需的。在分佈式SCM存在之前，仍然有可能這樣做。
每個開發人員都應該在他們自己的分支中工作（或者，您可能更喜歡降低分支粒度級別，比如每個bug或任務（特別是配對編程，或者同時開展許多任務的開發人員）。如果你有一個成熟的團隊而不是強加於他們，那麼他們可能會留給開發者。
開發人員應該儘早並經常進入他們自己的分支 - 它就像一個備份系統，它支持重要的點，並跟蹤您在進行更改時所考慮的內容
只將代碼審查分支合併回主分支。
分佈式SCM系統有很多好處，我不想聽起來像我反對他們，但如果你不使用它，這是沒有理由不使用每個開發人員的分支機構。
我相信在這種範式中早期承諾的障礙之一是心理/自我。通過集中的VCS，即使提交給一個私人分支，提交在歷史中也是永久可用的。開發人員不願意犯愚蠢的想法和死衚衕。 DVCS不存在這樣的問題;你可以按照自己想要的頻率進行提交，然後在發佈前進行清理。補丁序列讓你看起來像個天才。 – 2010-07-07 15:30:03
@William：你的意思是用git。其他DSCM相信保持歷史。 :) – 2010-07-07 16:00:21
@威廉，我理解你的理論。例如，我對ClearCase（其他人）的經驗是，這在實踐中不是問題。私人部門不會吸引其他人的興趣;我想不起任何開發人員在另一個人的私人分支中對代碼進行評論的例子。同樣，在企業環境中，你可能會走到別人的機器並登錄，但實際上人們（至少在我工作的文化中）不這樣做。 – Oddthinking 2010-07-08 00:57:32
使用分支。
例子：
上一個特性分支自己的分公司工作的離散事件。在與主線開發分支合併時對這些更改進行審查。在發佈時將開發分支與發佈分支合併。
你應該看看這個谷歌TechTalks由Linus Torvalds：http://www.youtube.com/watch?v=4XpnKHJAok8
萊納斯是explaigning爲什麼分佈式SCM（如Git或Hg）降低心理障礙承諾，從而允許開發者以「早提交，提交經常「（使用分支，感謝合併在git中如此簡單）。
然後，同行評審由其他人完成，將你的分支拉入他們的內部，檢查他們想檢查的任何內容，並運行測試套件。最後，當每個人都很開心時，你可以推到一個「活的」或「前生活」的分支，這個分支應該由一個被推動的團隊/人來維護。
就這樣說：「這不是我，這是萊納斯告訴它！」，應該有很大的幫助:)
我們使用Version Control for Multiple Agile Teams介紹的策略 - 工程也是一個團隊 - 和它的偉大工程爲了我們。
下面的插圖整個迭代：
並在很短的解釋：
我們在我們的「完成定義」中包含「代碼複審」，因此如果代碼未經審覈，故事不能從工作分支發佈到幹線。但是，人們可以在團隊的工作分支中儘早且經常地提交（只要代碼是單元測試的）。
我已經在幾個項目中使用了這種方法，多個規模（小團隊，一個團隊到多個團隊的大項目），以及包括Subversion在內的不同VCS成功。我建議閱讀整篇論文。
我感謝您的詳細解釋和圖表。這聽起來像一個我可以適應的政策，雖然它意味着與每個合併/衝突解決方案相關的一定量的開銷。它實際上顛倒了促使我問這個問題的主要問題。由於沒有官方「運送」的變化，我們經常會發生衝突和大量返工。 – Cliff 2010-07-08 15:05:37
@Cliff我對這個策略的經驗是，你不會得到太多的衝突（因爲人們關注的是特定的部分）。有時候，你會得到一些，但大部分時間，你不會，而且它很容易早日解決它們。現在，你顯然需要改變某個地方來解決你的問題（因爲你當前的策略阻止了不提交代碼審查的提交），並且在我看來，爲正在進行的工作和可釋放代碼設立單獨的分支是自然的解決方案。 – 2010-07-08 15:33:41
考慮在每個開發人員/對中添加額外（ad hoc？）分支，以用於您希望提交非單元測試代碼的情況（例如，在大型重構中）。 – Oddthinking 2010-07-08 16:10:23
不能評論所以 - 不同級別的分支策略（帕斯卡的回答）是偉大的。不過，我認爲你想澄清的一件事是「提交」是否等於「發佈」。它不應該。
我們一個團隊爲每個項目所做的工作就是開發人員在準備就緒時提交，但是提交不得違反單元測試的用法（類似於Pascal出色工作流程中的「單元測試」策略）。我們有一個測試服務器直接從存儲庫運行並在每次提交後更新（我們做web應用程序 - 這相當於每次提交或每天都構建軟件）。每個人都可以訪問該服務器，包括PO和利益相關者 - 事實上任何想要的人都可以使用它並提供反饋。
現在，代碼評審被指定爲針對每個項目的衝刺積壓工作的明確工作。沒有通過代碼評論的項目不被視爲已完成，並且不屬於在衝刺結束時發佈的可交付增量的一部分。
在這種情況下，「提交」是指將代碼發送到回購站。您的代碼對其他人可見，在測試服務器上也可見（如果它不會破壞某些內容）。心理障礙遠低於承諾意味着發送被認爲可釋放的東西。儘管如此，每個開發人員都知道他們的代碼在代碼審查之前不會真正發佈，如果他們發送一個會破壞單元測試的提交，他們將不得不在一天的其餘時間佩戴一個有趣的帽子。對於代碼審查需要時間 - 好，這是花費時間，花時間投入更高的產品質量。很值得。
如果你正在尋找一個混合，我可以建議採用一個新的政策：成對生產的代碼不需要代碼審查。
配對編程提供了與代碼審查相同的價值，允許出色的知識轉移，並幫助新手程序員（有時也是有經驗的程序員！）快速學習。當然，它帶來了自己的挑戰......它們都不可能無法克服。
我所在的團隊採用了類似的政策，即在沒有審查的情況下不會提交任何代碼，但我們解決這個問題的方式是做幾乎獨一無二的結對編程。有些人可能會認爲這並不構成「審查」，但它確實確保至少有兩名開發人員完成了代碼，設計和測試。在辦理登機手續時，兩位審覈人員輸入他們的首字母進行追蹤。
不知道這是否會與您的審查委員會，但你可能要考慮的東西。
相關/有趣的問題：http://stackoverflow.com/questions/20327/code-review-vs-check-in-often和http://stackoverflow.com/questions/2704996/describe-your-workflow-使用版本控制-vcs-or-dvcs – 2010-07-07 15:26:49
至少，代碼需要保存在安全的地方，即在代碼審查之前。如果需要的話，它應該是別人可以到達的地方。然而，每個人都必須尊重這樣一個事實，即這段代碼是一項正在進行的工作，所以沒有人應該指責別人在其分支中編寫錯誤的代碼。 – apollodude217 2010-07-17 15:32:44
我投票結束這個問題作爲題外話題，因爲這是一個民意調查。 – EJoshuaS 2017-11-17 16:28:26