在這篇文章中，我提出一個開發(fā)模型。我已經(jīng)將這個開發(fā)模型引入到我所有的項目里(無論在工作還是私人)已經(jīng)一年有余，并且它被證明是非常成功的。我打算寫這些已經(jīng)很久了，但我一直找不到時間來做，現(xiàn)在終于有時間了。我不會講任何項目的具體細節(jié)，僅是關于分支策略和釋放管理相關內(nèi)容。

　　它主要體現(xiàn)了Git對我們源代碼版本的管理。

　　為何是Git?

　　對于Git與其他集中式代碼管理工具相比的優(yōu)缺點的全面討論，請參見這里。這樣的爭論總是喋喋不休。作為一個開發(fā)者，與現(xiàn)今的其他開發(fā)工具相比較，我更喜歡Git。Git真得改變了開發(fā)者對于合并和分支的思考。我曾經(jīng)使用經(jīng)典的CVS/Subversion，然而每次的合并/分支和其他行為總讓人擔驚受怕(“小心合并里的沖突，簡直要命!”)。

　　但是對于Git來說，這些行為非常簡單和搞笑，它們被認為是日常工作中的核心部分。例如，在很多CVS/Subversion書里，分支與合并總是在后面的章節(jié)中被討論(對于高級用戶使用)，然而在每個Git書中，在第3章已經(jīng)完全涵蓋了(作為基礎)。

　　簡單和重復的特性帶來的結果是：分支與合并不再是什么可以害怕的東西。分支/合并被認為對于版本管理工具比其他功能更重要。

　　關于工具，不再多說，讓我們直接看開發(fā)模型吧。這個模型并不是如下模型：在管理軟件開發(fā)進度方面，面對每個開發(fā)過程，每個隊員必須按一定次序開發(fā)。

　　分布式而非集中式

　　對于這種分支模型，我們設置了一個版本庫，它運轉良好，這是一個”事實上” 版本庫。不過請注意，這個版本庫只是被認為是中心版本庫(因為Git是一個分布式版本管理系統(tǒng)，從技術上來講，并沒有一個中心版本庫)。我們將把這個版本庫稱為原始庫，這個名字對所有的Git用戶來說都很容易理解。

　　每個開發(fā)者都對origin庫拉代碼和提交代碼。但是除了集中式的存取代碼關系，每個開發(fā)者也可以從子團隊的其他隊友那里獲得代碼版本變更。例如，對于2個或多個開發(fā)者一起完成的大版本變更，為了防止過早地向origin庫提交工作內(nèi)容，這種機制變得非常有用。在上述途中，有如下子團隊：Alice和Bob，Alice和David，Clair和David。