存儲庫組織

當我第一次開始使用版本控制系統如CVS和SVN時，我並沒有真正理解「trunk」，分支，合併和標記的概念。我現在開始理解這些概念，並真正瞭解它們的重要性和力量。存儲庫組織

所以，我開始正確地做。或者所以我認爲...這是我目前瞭解的內容：代碼的最新版本/穩定版本應該位於/ trunk /中，而beta版本或流血版本位於/ branches /目錄內作爲每個測試版的不同目錄釋放，然後在釋放時合併到主幹中。

這是對事物過於簡單化的看法嗎？你們建議什麼樣的存儲庫佈局？如果它有所作爲，我使用Subversion。

來源

2008-08-20 mercutio

看到這兩個問題上的SO瞭解更多信息：

來源

2008-08-20 11:06:07

我做什麼，通常會看到一個標準是：

樹幹應該包含你的主要發展路線，你的不穩定版本。您應該爲您的版本創建發佈分支。

喜歡的東西：

/中繼線（這裏你正在開發2.0版） /branches/RB-1.0（這是1.0發佈分支） /branches/RB-1.5

當你在1.5中找到一個bug，將其修復到RB分支中，然後合併到主幹。我也推薦this book。

來源

2008-08-20 11:10:16

Eric擁有一系列關於源代碼管理使用和組織最佳實踐的優秀系列文章。 Chapter 7 deals with branches（是的，它建議您建議/ trunk /和/ branches /目錄）。

來源

2008-08-20 11:28:43

我已經使用Perforce很長一段時間了，所以我的評論可能會以Perforce爲中心，但基本原則適用於任何具有一半體面分支的SCM軟件。我是一個非常堅信使用分支開發實踐的人。我有一個「主」（又名「主線」），代表從現在到永恆的代碼庫。目標是在大多數情況下，這是穩定的，如果推動推進，您可以在任何時候削減發佈，以反映系統的當前功能。那些討厭的銷售人員不斷詢問......

開發發生在從MAIN分支的分支（通常 - 偶爾你可能想從現有的開發分支分支）。儘可能多地從MAIN集成到您的開發分支，以防止事態分化過度 - 或者您可以稍後爲更大的集成時間預算。只有當你確信它將在即將發佈的版本中發佈時，才能將你的屁股與新的功能結合起來。

最後，你有一個RELEASE行，這是不同版本的不同分支的選項。有一些選擇取決於SCM軟件的標籤功能，以及主要/次要修訂可能有多不同。因此，例如，您可以選擇每個發佈版本的發佈分支，或者僅限於主版本號。你的旅費可能會改變。

一般來說，從MAIN分支到儘可能晚的發佈。錯誤修復和最後一分鐘更改可以直接進入RELEASE以便稍後集成到MAIN，也可以直接進入MAIN進行即時集成備份。沒有硬性規定 - 做最好的做法。但是，如果您有可能會提交給MAIN的更改（例如，來自開發分支，或MAIN上的某個人「稍作調整」），則執行前者。這取決於你的團隊如何工作，你的發佈週期是什麼等。

E.g.我會有這樣的事情：

//MYPROJECT/MAIN/... - the top level folder for a complete build of all the product in main. 
//MYPROJECT/DEV/ArseKickingFeature/... - a branch from MAIN where developers work. 
//MYPROJECT/RELEASE/1.0/... 
//MYPROJECT/RELEASE/2.0/...

一個不平凡的項目可能會有多個DEV分支同時活動。當一個開發已經集成到MAIN中，以便它現在成爲核心項目的一部分時，儘可能快地關閉舊的DEV分支。許多工程師會將DEV分支視爲他們自己的個人空間，並隨着時間的推移將其重用於不同的功能。勸阻這一點。

如果在發佈之後，您必須修復一個bug，然後在相應的發佈分支中執行該操作。如果之前在MAIN中已經修復了該錯誤，則整合，除非MAIN中的代碼已經發生了很大的變化，修正則不同。

真正區分代碼行的是您用來管理它們的策略。例如，哪些測試運行，哪些人評論變更前/變更後，如果構建中斷，會發生什麼操作。通常情況下，策略 - 因此開銷 - 在發佈分支中最強，在DEV中最弱。有一篇文章here經歷了一些場景，並鏈接到其他有用的東西。

最後，我建議以一個簡單的結構開始，並根據需要只引入額外的dev &版本。

希望能夠幫助，而不是說出血 - 顯然太多了。

來源

2008-08-20 11:37:35

回答

相關問題