分支策略

我工作的公司開始遇到與他們當前的分支模型有關的問題，我想知道社區接觸到了哪些不同類型的分支策略？分支策略

對於不同的情況有沒有什麼好的方法？貴公司使用什麼？他們的優點和缺點是什麼？

來源

2008-08-29 Craig H

閱讀本經典：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf – zvolkov 2009-04-15 23:41:54

@casperOne這可能是最有趣的方式來處理一個鏈接的答案標誌我見過 – gnat 2012-02-24 20:48:18

@gnat來部分包裹與答案上的國旗處理。 =） – casperOne 2012-02-24 21:13:14

我強烈鼓勵閱讀埃裏克庫的意見對此事：

Chapter 7: Branches

我，像埃裏克，喜歡的分支，他談到了「文件夾」的風格。

來源

2008-08-29 18:41:04

埃裏克說：「簡單的變化，正如我在我的」埃迪「情景中提到的，不要爲每個錯誤修復或功能分支。」但是隨着新的SCMs的出現，這不再是事實。 SVN的人們常常說，直到他們實現了正確的分支......而GIT的人將永遠不會這麼說...... 但通常情況下，某個版本控制背後的人會說他們不能做的事情是不值得的......： - （ – pablo 2009-04-27 22:46:54

這將取決於您正在使用的版本控制系統。每個VCS都有不同的分支方法。

您使用哪個VSC？

來源

2008-08-29 18:42:15

我們目前有一個分支機構正在進行維護，其中一個分支機構爲「新舉措」，意思是「將來某個時候出來的東西;我們不確定何時」。我們偶爾還會有兩個維護分支機構：一個爲目前正在生產的產品和一個仍在質量保證中的產品提供修復。

我們看到的主要優勢是能夠更快速地對用戶請求和緊急情況做出反應。我們可以對正在生產的分支進行修復並釋放它，而不會釋放任何可能已經檢入的額外內容。

主要缺點是我們最終在分支之間進行了大量合併，這增加了分支之間的合併有可能錯過或錯誤地合併。到目前爲止，這並不是一個問題，但它絕對是要記住的。

在我們制定這項政策之前，我們通常在幹線中做了所有的開發工作，並且只在我們發佈代碼時進行分支。然後，我們根據需要對該分支進行了修復。這很簡單，但不夠靈活。

來源

2008-08-29 18:42:37

我們在工作中遵循的理念是保持樹幹處於可隨時推動的狀態，而不會對網站造成嚴重傷害。這並不是說幹線總是處於完美的狀態。當然會有錯誤。但重要的是永遠不要讓它大打折扣。

如果您有要添加的功能，分支。設計更改，分支。我曾經想過很多次，「噢，我可以在後備箱裏做這件事，不會花費那麼長時間」，然後5個小時後，當我無法弄清楚那個破壞我的東西的錯誤時真的希望我有分支。

當您保持行李箱乾淨時，您可以讓機會快速應用並推出錯誤修復程序。您不必擔心您方便分支的破解代碼。

來源

2008-08-29 18:52:40

對於Subversion，我同意Ryan Duffield的評論。他提到的這一章提供了一個關於使用哪個系統的良好分析。

我問的原因是，Perforce提供了一種完全不同的方式來從SVN或CVS創建分支。另外，還有所有的DVCS都有自己的分支哲學。您的分支策略將由您正在使用的工具決定。

僅供參考，Svnmerge.py是一個工具，用於協助合併SVN中的分支。只要你經常使用它（每10-30次），它就會工作得很好，否則工具會變得混亂。

來源

2008-08-29 18:52:44

我們在發佈準備好進行最終質量檢查時進行分支。如果在質量保證過程中發現任何問題，則錯誤在分支中得到修復，驗證併合併到中繼。一旦分支通過QA，我們將其標記爲發佈。該版本的任何修補程序也會對分支進行修改，驗證，合併到中繼，然後標記爲單獨的版本。

的文件夾結構應該是這樣的（1個QA線，2級修復程序的版本中，與軀幹）：

/分支

/REL-1.0

/標籤

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/後備箱

來源

2008-08-29 19:02:08

這是我在與良好的成功過去使用的方法：

/樹幹 - 出血邊緣。下一個主要版本的代碼。可能在任何時候或可能不工作。

/branches/1.0,1.1等代碼的穩定維護分支。用於修復錯誤，穩定新版本。如果維護分支，它應該編譯（如果適用）並準備在任何給定時間進行質量保證/運輸。如果是穩定分支，它應該編譯並且功能完整。不應添加任何新功能，不要重構，也不要執行代碼清理。您可以添加前綴來指示穩定分支與維護分支。

/branches/cool_feature。用於高度實驗性或破壞性工作，可能會或可能不會將其變成後備箱（或維修分部）。沒有關於代碼編譯，工作或其他行爲的保證。在合併到主線分支之前應儘可能保持最短時間。

/tags/1.0.1,1.0.2,1.1.3a等等。用於標記已包裝的&發貨版本。永遠不會改變。儘可能多地創建標籤，但它們是不可變的。

來源

2008-08-29 19:17:18 jcoby

我們使用野生，野生，西方風格的git分支。我們有一些根據慣例定義的着名名稱的分支機構，但在我們的案例中，標籤實際上對我們來說更重要，以滿足我們的企業流程政策要求。

我在下面看到你使用Subversion，所以我想你可能應該看看關於在Subversion Book分支的部分。具體來說，請查看Branch Maintenance和Common Branch Patterns中的「資源庫佈局」部分。

來源

2008-08-29 19:23:20

我們的庫看起來像是：

/trunk 
/branches 
/sandbox 
/vendor 
/ccnet

/後備箱是標準的，前沿的發展。我們使用CI，因此必須始終構建並通過測試。

/branches這是我們把'認可'的大變化，也就是我們知道的東西會變成樹幹，但可能需要一些工作並會破壞CI。我們也在維護版本的工作中，這些維護版本有自己的CI項目。

/沙箱每個開發人員都有自己的沙箱，以及共享的沙箱。這是針對諸如「讓我們的產品添加一個LINQ提供程序」類型的任務，當您沒有進行真正的工作時所做的任務。它最終可能會進入主幹，它可能不會，但它在那裏，並在版本控制下。這裏沒有CI。

/vendor我們編譯的項目的標準供應商分支，但它不是我們維護的代碼。

/ccnet這是我們的CI標籤，只有CI服務器可以在這裏寫入。後見之明本來會告訴我們將其重新命名爲CI，BUILDS等更通用的東西。

來源

2008-09-12 16:56:08

我在這裏沒有看到的替代方案是「分支變革」哲學。

而不是讓你的樹幹「狂野的西部」，如果樹幹是「當前版本」會怎麼樣？如果一次只發佈一個版本的應用程序（如網站），則此方法可行。當需要新功能或錯誤修復時，分支會保留該更改。通常這可以將修補程序逐個遷移到單獨發行版，並防止您的牛仔編碼器無意中添加一個功能以釋放您不想要的功能。（通常這是一個後門 - 「僅用於開發/測試」）

本柯林斯的指針在確定哪種風格適合您的情況非常有用。

來源

2008-09-15 17:37:47

Henrik Kniberg的Version Control for Multiple Agile Teams也有一些優點要考慮。

來源

2008-09-18 22:13:21

對於分支模式的母親，請參閱Brad Appleton的Streamed Lines: Branching Patterns for Parallel Software Development。這是沉重的責任，但我沒有看到任何東西超過它的分支知識的廣度和深度。

來源

2008-09-26 16:32:06

Jeff Atwood wrote關於此在一個很好的博客文章;該帖子中有一些重要的鏈接。爲積極發展

來源

2008-10-24 10:51:11 spinodal

一個分支（/主或主，根據不同的行話）
每個維護版本的一個分支 - >將只接收非常小的修正，而所有主要的發展進入/主
每個新任務的一個分支：創建一個新的分支來處理Bugzilla/Jira/Rally上的每個新條目。經常提交，使用英寸鵝卵石檢查自行記錄更改，並且只有在完成並經過良好測試後纔將其合併回「其父」分支。

看看這個http://codicesoftware.blogspot.com/2010/03/branching-strategies.html一個更好的解釋

來源

2009-04-27 22:41:35 pablo

不管是哪個分支模式選擇，你應該儘量保持你的分支在一個二進制樹形式是這樣的：

trunk - tags 
    | 
    next 
/\ \ 
bugfix f1 f2 
     / \ \   
     f11 f21 f22

子節點只應與直接父級合併。
試試你最好只合並整個分支與父分支。從不合並分支內的子文件夾。
只要您只合並並從整個分支中挑選，您可以在需要時選擇提交。
上圖中的下一個分支僅用於說明，您可能不需要它。

來源

2010-03-17 09:27:35

的第一件事：KISS（！保持簡單愚蠢）

 
/branches 
    /RB-1.0 (*1) 
    /RB-1.1 (*1) 
    /RB-2.0 (*1) 
/tags 
    /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2) 
    /REL-1.1 
    /REL-2.0 
/trunk 
    current development with cool new features ;-)

* 1）保持版本維護 - 例如服務包，修補程序，錯誤修正，其可被合併到主幹如果必要和/或需要的話） * 2）major.minor.build.revision拇指

規則：

的標籤的文件夾不必在發佈分支被檢查出
只有很少的編碼（使合併更簡單） - 無碼清理等
從未在標籤文件夾編碼
不要把具體版本信息爲源文件。使用佔位符或0.0.0.0，其構建機制將由您正在編譯的版本號替換
永遠不要將第三方庫放入源代碼管理中（也沒有人會將STL，MFC等庫添加到SVN中; - ））
只有提交，編譯
不想使用環境變量，而不是硬編碼路徑（絕對和相對路徑）

--hfrmobile

來源

2011-01-05 14:48:30 hfrmobile

蚋已在各個位寫this excellent break down代碼你可以在branc上找到的建議興戰略。

這裏沒有一個分支策略，它就是適用於：

你的團隊規模
你的產品和生命週期階段
您正在使用的技術（網絡，嵌入式的Windows應用程序）
您的源代碼管理，例如Git，TFS，Hg

Jeff Atwood的post打破了很多可能性。另一個要補充的是促銷的概念（來自Ryan Duffield的鏈接）。在這個設置中你有一個開發分支，測試bracnh和發佈分支。直到它到達發佈分支並進行部署之前，您都會提升代碼。

來源

2011-10-19 11:10:26

回答

相關問題