使用源控制時，我習慣的工作方式是在主幹上開發，然後在進入QA之前分支主幹。源控制分支的不同方法
我正在和部門的其他人談話，顯然對於不同的工作方式有一些激情的看法，那就是在開發週期的最初階段創建新的分支，分支，然後在末尾將它合併回主幹。這種方法的想法是保持原始狀態。
雖然我對一個支持者認爲後一種方法是「標準」方法（雖然很高興被告知除此之外）的說法持高度懷疑態度，但我不會驚訝於聽說它很常見。我可以想象一些好處（更容易選擇何時部署哪些功能或一組功能），但也有一些缺點（潛在的合併問題，因爲每個分支必須合併回主幹）。
做了一些後來的研究，發現這個：http://www.lostechies.com/blogs/derickbailey/archive/2009/07/15/branch-per-feature-source-control-introduction.aspx
會好奇，從人他們對這些方法的相對優勢和劣勢感都聽到，也關於人們可使用任何其它方法。
這是一個非常類似的問題這個以前SO項目：
Subversion - should anyone be developing off the trunk?
並不完全相同，但很多的響應中的概念是相同的。
我的用戶意見是？幹線是積極發展的;應該在版本分支（和發行版的標籤）中保留要保持「原始」的舊版本的開發線。即使在主幹上進行了積極的開發，您仍然可以嘗試維持「幹線應始終彙編」的格言。
由於一個團隊正在開發相同的工作，所以這是一個非常好的工作方式，在發佈之前創建一個分支。你最小化合並地獄，如果你必須做一個補丁，或者由於某種原因返回，你對每個版本都有一個獨特的分支。
但是，當與多個團隊合作做單獨的事情時，這將不起作用，因爲他們肯定會在後備箱中發生碰撞。我對此沒有太多經驗，所以我期待着圍繞這一點的一些想法。一種方法是擁有多個分支，也許每個分支都有一個分支，然後合併那些正在進入發行版的分支。 （我只能想象沮喪）:)
或使用「主題分支」工作流程，其中每個單獨的功能都是在單獨的分支上開發的。不過，我不知道Subversion能夠如何工作。這是Git使用的工作流程。 – 2009-08-27 10:50:33
是的，這可能會更好，因爲代碼中的特徵通常相互獨立。它可能工作得很好，只要相同的代碼行沒有改變，Subversion就擅長合併代碼。 – crunchdog 2009-08-27 15:36:26
我贊成保持乾淨。這允許隨時編譯工作版本，發佈修正，測試版本，創建演示版本...
對分離的分支進行更改。這提供了更好的可追溯性，並且可以利用分支上的源代碼控制並檢入臨時版本。在理想的世界中，合併問題由[自動]測試覆蓋。越早將更改整合到主幹中越好。
請勿將未經測試的代碼放在主幹上，因爲這最終會使某人變慢。
吶，這正是我一直在尋找的。謝謝。 – 2009-08-26 06:48:45
是的，我有同樣的觀點，但我可以認識到，至少目前（對我而言）只是歷史偏見而已。在您提供的鏈接中，每個陣營中都有一些有趣的回覆... – 2009-08-26 06:52:53