本文并非專為版本控制專家所寫，實際上這樣的專家在本文中找不到新東西。本文是為我們這些希望進行簡單、有效的協作的人所準備的。任何直接參與敏捷軟件開發的人，無論他承擔何種角色，都有可能對其感興趣——每個人都會用到分支和合并，而不只是配置經理。
介紹
本文講述了關于如何在敏捷的環境中與多個團隊共同進行版本控制工作的實例。我假定你已經熟悉了Scrum的基本元素、XP方法和任務板。這些方式不是我發明的，它們是基于“主線（mainline）模型”或“穩定主干（stable trunk）模式”。想閱讀更多信息請查看引用部分。
撰寫本文，是因為我一直在遇到需要類似內容的團隊。許多團隊在理解了模型之后，似乎非常喜歡這些模型。它也正是我們在《Scrum and XP from the Trenches》中描述的公司所采納的方式。它真的可以幫助我們以更敏捷的方式來開發和發布軟件。通過以易于閱讀的方式來描述模型，也許我不再需要反復在白板前做解釋了。:o)
注意這只是眾多模式中的一種，不是“銀彈“。如果你決定采用該模型，也許你需要做出一些變更來適應你自己的特定上下文。
目標
在多個團隊構成的敏捷環境中，版本控制模型必須達成以下目標：
快速失敗
代碼沖突和集成問題應該可以被迅速發現。
經常修復小問題要勝過不常修復大問題。
一直可發布
即使經歷了一個混亂的Sprint，也要保證至少有些可以發布的內容。
簡單
所有的團隊成員每天都會使用這些模式，所以相關規則和程序必須要簡單明了。
單頁總結（對于掛在墻上的內容）
如果該圖讓你覺得很迷惑，別著急，閱讀本文即可。如果其中的理念對你來說很明顯，讀讀本文也無妨。
文章來源于領測軟件測試網 http://www.kjueaiud.com/