介紹一個成功的 Git 分支模型

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

　　它主要體現了Git對我們源代碼版本的管理。

　　為何是Git?

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

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

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

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

　　分布式而非集中式

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

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

　　從技術上將，這意味著，Alice創建了一個Git的遠程節點，而對于Bob，該節點指向了Bob的版本庫，反之亦然。

　　主分支

　　在核心部分，研發模型很大程度上靠其他現有模型支撐的。中心庫有2個可一直延續的分支：

　　master分支

　　develop分支

　　每個Git用戶都要熟悉原始的master分支。與master分支并行的另一個分支，我們稱之為develop分支。

　　我們把原始庫/master庫認作為主分支，HEAD的源代碼存在于此版本中，并且隨時都是一個預備生產狀態。

　　輔助性分支

　　我們的開發模型使用了各種輔助性分支，這些分支與關鍵分支(master和develop)一起，用來支持團隊成員們并行開發，使得易于追蹤功能，協助生產發布環境準備，以及快速修復實時在線問題。與關鍵分支不同，這些分支總是有一個有限的生命期，因為他們最終會被移除。

　　我們用到的分支類型包括：

　　功能分支

　　發布分支

　　熱修復分支

　　每一種分支有一個特定目的，并且受限于嚴格到規則，比如：可以用哪些分支作為源分支，哪些分支能作為合并目標。我們馬上將進行演練。

　　從技術角度來看，這些分支絕不是特殊分支。分支的類型基于我們使用的方法來進行分類。它們理所當然是普通的Git分支。

　　功能分支

　　可能是develop分支的分支版本，最終必須合并到develop分支中。

　　分支命名規則：除了master、develop、release-*、orhotfix-*之外，其他命名均可。

　　功能分支(有時被稱為topic分支)通常為即將發布或者未來發布版開發新的功能。當新功能開始研發，包含該功能的發布版本在這個還是無法確定發布時間的。功能版本的實質是只要這個功能處于開發狀態它就會存在，但是最終會或合并到develop分支(確定將新功能添加到不久的發布版中)或取消(譬如一次令人失望的測試)。

　　功能分支通常存在于開發者的軟件庫，而不是在源代碼庫中。

　　創建一個功能分支

　　開始一項功能的開發工作時，基于develop創建分支。

　　合并一個功能到develop分支

　　完成的功能可以合并進develop分支，以明確加入到未來的發布：

原文轉自：http://blog.jobbole.com/34706/