在這篇文章中，我提出一個開發模型。我已經將這個開發模型引入到我所有的項目里(無論在工作還是私人)已經一年有余，并且它被證明是非常成功的。我打算寫這些已經很久了，但我一直找不到時間來做，現在終于有時間了。我不會講任何項目的具體細節，僅是關于分支策略和釋放管理相關內容。
它主要體現了Git對我們源代碼版本的管理。
為何是Git?
對于Git與其他集中式代碼管理工具相比的優缺點的全面討論，請參見這里。這樣的爭論總是喋喋不休。作為一個開發者，與現今的其他開發工具相比較，我更喜歡Git。Git真得改變了開發者對于合并和分支的思考。我曾經使用經典的CVS/Subversion，然而每次的合并/分支和其他行為總讓人擔驚受怕(“小心合并里的沖突，簡直要命!”)。
但是對于Git來說，這些行為非常簡單和搞笑，它們被認為是日常工作中的核心部分。例如，在很多CVS/Subversion書里，分支與合并總是在后面的章節中被討論(對于高級用戶使用)，然而在每個Git書中，在第3章已經完全涵蓋了(作為基礎)。
簡單和重復的特性帶來的結果是：分支與合并不再是什么可以害怕的東西。分支/合并被認為對于版本管理工具比其他功能更重要。
關于工具，不再多說，讓我們直接看開發模型吧。這個模型并不是如下模型：在管理軟件開發進度方面，面對每個開發過程，每個隊員必須按一定次序開發。
分布式而非集中式
對于這種分支模型，我們設置了一個版本庫，它運轉良好，這是一個”事實上” 版本庫。不過請注意，這個版本庫只是被認為是中心版本庫(因為Git是一個分布式版本管理系統，從技術上來講，并沒有一個中心版本庫)。我們將把這個版本庫稱為原始庫，這個名字對所有的Git用戶來說都很容易理解。
每個開發者都對origin庫拉代碼和提交代碼。但是除了集中式的存取代碼關系，每個開發者也可以從子團隊的其他隊友那里獲得代碼版本變更。例如，對于2個或多個開發者一起完成的大版本變更，為了防止過早地向origin庫提交工作內容，這種機制變得非常有用。在上述途中，有如下子團隊：Alice和Bob，Alice和David，Clair和David。
