Git Flow

Git的優勢

Git的優勢不少，可是這裏只列出我認爲很是突出的幾點。

1. 因爲是分佈式，全部本地庫包含了遠程庫的全部內容。
2. 優秀的分支模型，打分支以及合併分支，機器方便。
3. 快速，在這個時間就是金錢的時代，Git因爲代碼都在本地，打分支和合並分支機器快速，使用個SVN的能深入體會到這種優點。

感興趣的，能夠去看一下Git自己的設計，內在的架構體現了不少的優點，不愧是出資天才程序員Linus (Linux之父) 之手

版本管理的挑戰

雖然有這麼優秀的版本管理工具，可是咱們面對版本管理的時候，依然有很是大得挑戰，咱們都知道你們工做在同一個倉庫上，那麼彼此的代碼協做必然帶來不少問題和挑戰，以下：

1. 如何開始一個Feature的開發，而不影響別的Feature？
2. 因爲很容易建立新分支，分支多瞭如何管理，時間久了，如何知道每一個分支是幹什麼的？
3. 哪些分支已經合併回了主幹？
4. 如何進行Release的管理？開始一個Release的時候如何凍結Feature, 如何在Prepare Release的時候，開發人員能夠繼續開發新的功能？
5. 線上代碼出Bug了，如何快速修復？並且修復的代碼要包含到開發人員的分支以及下一個Release?

大部分開發人員如今使用Git就只是用三個甚至兩個分支，一個是Master, 一個是Develop, 還有一個是基於Develop打得各類分支。這個在小項目規模的時候還勉強能夠支撐，由於不少人作項目就只有一個Release, 可是人員一多，並且項目週期一長就會出現各類問題。

Git Flow

就像代碼須要代碼規範同樣，代碼管理一樣須要一個清晰的流程和規範

Vincent Driessen 同窗爲了解決這個問題提出了 A Successful Git Branching Model

下面是Git Flow的流程圖

上面的圖你理解不了？ 不要緊，這不是你的錯，我以爲這張圖自己有點問題，這張圖應該左轉90度，你們應該就很用以理解了。

Git Flow經常使用的分支

• Production 分支

也就是咱們常用的Master分支，這個分支最近發佈到生產環境的代碼，最近發佈的Release， 這個分支只能從其餘分支合併，不能在這個分支直接修改

• Develop 分支

這個分支是咱們是咱們的主開發分支，包含全部要發佈到下一個Release的代碼，這個主要合併與其餘分支，好比Feature分支

• Feature 分支

這個分支主要是用來開發一個新的功能，一旦開發完成，咱們合併回Develop分支進入下一個Release

• Release分支

當你須要一個發佈一個新Release的時候，咱們基於Develop分支建立一個Release分支，完成Release後，咱們合併到Master和Develop分支

• Hotfix分支

當咱們在Production發現新的Bug時候，咱們須要建立一個Hotfix, 完成Hotfix後，咱們合併回Master和Develop分支，因此Hotfix的改動會進入下一個Release

Git Flow如何工做

初始分支

全部在Master分支上的Commit應該Tag

Feature 分支

分支名 feature/*

Feature分支作完後，必須合併回Develop分支, 合併完分支後通常會刪點這個Feature分支，可是咱們也能夠保留

Release分支

分支名 release/*

Release分支基於Develop分支建立，打完Release分以後，咱們能夠在這個Release分支上測試，修改Bug等。同時，其它開發人員能夠基於開發新的Feature (記住：一旦打了Release分支以後不要從Develop分支上合併新的改動到Release分支)

發佈Release分支時，合併Release到Master和Develop， 同時在Master分支上打個Tag記住Release版本號，而後能夠刪除Release分支了。

維護分支 Hotfix

分支名 hotfix/*

hotfix分支基於Master分支建立，開發完後須要合併回Master和Develop分支，同時在Master上打一個tag

感謝博主的辛苦分享，個人實踐在https://git.oschina.net/QAAQ/learn_GitFlow，只是沒有實踐打補丁的hotfix方式，我使用的eclipse，git插件，有任何問題均可以交流。