當我們最初設置版本控制時，我們的時間非常有限，只有基本知識如何設置。我們不理解分支，中繼或標籤。我們一直在處理的是Checkout，Update和Commit（哦，偶爾還有衝突）。我是否設置了subversion Repository錯誤？
但是現在，我們已經得到的地方，我們認爲，我們需要更好地瞭解它，並可能重新思考的方式我們的資料庫是設置和工作過的一個階段。
目前，我們有我們的服務器上的4名不同的文件夾，每個包含結帳。這4個區域具有用於生產的源代碼。這些結賬中的2個直接作爲缺陷修復結賬區域進行工作。其他2個用作開發結賬。團隊成員可以在更長時間的工作中工作的地方。一旦他們完成了開發任務，他們將其提交到存儲庫，並因此將其更新到所有其他簽出的生產代碼。
但是，當閱讀關於分支時，它聽起來像在這裏有一個失蹤的水平。一根樹幹，我認爲它是它所稱的。
有人可以給這個newb一點快速崩潰corse如何正確的方法是爲團隊或開發人員設置一個存儲庫，他們需要一種方法來執行生產代碼的快速錯誤修復，但也運行一對夫婦發展？
儘量先閱讀一些文章。然後回來更具體的問題。我認爲這是很好的文章：http://nvie.com/posts/a-successful-git-branching-model/
簡而言之，您將源代碼作爲一批補丁管理。您作爲提交進行的每個更改都是一組修補程序。然後你可以將這些補丁組合成特定的產品版本。此外，VCS允許保留所有歷史記錄，併爲您提供每個已發佈版本的可重複性。
這說明資源與圖形可視化分支可能對您有用：http://nvie.com/posts/a-successful-git-branching-model/
想想這樣：你想要一個'trunk'，它是你所有產品代碼的主版本。但是你不想一直對它進行修改 - 總有一天你會想要獲得最新版本的產品，而且，恐怖的是，開發人員通過做出的改變不是中途還有工作。最重要的是，假設你發現最新版本有問題，你需要獲取最後一個版本（你知道的一個版本）。
那麼，分支機構就是這裏的答案。在Subversion中有兩種不同類型的分支，稱爲分支和標籤。他們真的是一樣的東西，但人們稱他們爲不同的名稱來區分你使用它們的用途。
與以前一樣，您擁有自己的主幹，但是現在，當開發人員想要進行更改時，首先將主幹複製到新分支中。開發人員可以安全地在該分支上工作。一旦他完成，您將更改複製回主幹。 Svn（以及所有其他人）都有工具來幫助將變化重新合併到主幹上。
當您想要保留「完成」版本時，您可以做同樣的事情 - 將其複製到具有唯一名稱的標籤分支上（例如版本1）。不同的是，你永遠不會改變這個分支。它是固定的，不變的，併爲您提供了識別構成該版本的代碼（僅代碼）的方法。
就是這樣。你可以有多個分支進行開發，你可以從一個標籤發佈分支來進行錯誤修正，或者你總是可以從分支中分支來創建錯誤修正 - 你如何做到這一點取決於你想如何工作。