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

　　創(chuàng)建一個功能分支

　　開始一項功能的開發(fā)工作時，基于develop創(chuàng)建分支。

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

　　合并一個功能到develop分支

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

 
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

　　–no-ff標志導致合并操作創(chuàng)建一個新commit對象，即使該合并操作可以fast-forward。這避免了丟失這個功能分支存在的歷史信息，將該功能的所有提交組合在一起。 比較:

　　后一種情況，不可能從Git歷史中看到哪些提交一起實現了一個功能——你必須手工閱讀全部的日志信息。如果對整個功能進行回退 (比如一組提交)，后一種方式會是一種真正頭痛的問題，而使用–no-ffflag的情況則很容易.

　　是的，它會創(chuàng)建一個新的(空)提交對象，但是收益遠大于開銷。

　　不幸的是，我還沒找到一種方法，讓–no-ff時作為合并操作的默認選項，但它應該是可行的。

　　Release 分支

　　Release分支可能從develop分支分離而來，但是一定要合并到develop和master分支上，它的習慣命名方式為：release-*。

　　Release分支是為新產品的發(fā)布做準備的。它允許我們在后時刻做一些細小的修改。他們允許小bugs的修改和準備發(fā)布元數據(版本號，開發(fā)時間等等)。當在Release分支完成這些所有工作以后，對于下一次打的發(fā)布，develop分支接收features會更加明確。

　　從develop分支創(chuàng)建新的Release分支的關鍵時刻是develop分支達到了發(fā)布的理想狀態(tài)。至少所有這次要發(fā)布的features必須在這個點及時合并到develop分支。對于所有未來準備發(fā)布的features必須等到Release分支創(chuàng)建以后再合并。

　　在Release分支創(chuàng)建的時候要為即將發(fā)行版本分配一個版本號，一點都不早。直到那時，develop分支反映的變化都是為了下一個發(fā)行版，但是在Release分支創(chuàng)建之前，下一個發(fā)行版到底叫0.3還是1.0是不明確的。這個決定是在Release分支創(chuàng)建時根據項目在版本號上的規(guī)則制定的。

　　創(chuàng)建一個release分支

　　Release分支是從develop分支創(chuàng)建的。例如，當前產品的發(fā)行版本號為1.1.5，同事我們有一個大的版本即將發(fā)行。develop 分支已經為下次發(fā)行做好了準備，我們得決定下一個版本是1.2(而不是1.1.6或者2.0)。所以我們將Release分支分離出來，給一個能夠反映新版本號的分支名。

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully， version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed， 1 insertions(+)， 1 deletions(-)

　　創(chuàng)建新分支以后，切換到該分支，添加版本號。這里，bump-version.sh 是一個虛構的shell腳本，它可以復制一些文件來反映新的版本(這當然可以手動改變–目的是修改一些文件)。然后版本號被提交。

　　這個新分支可能會存在一段時間，直到該發(fā)行版到達它的預定目標。在此期間，bug的修復可能被提交到該分支上(而不是提交到develop分支上)。在這里嚴格禁止增加大的新features。他們必須合并到develop分支上，然后等待下一次大的發(fā)行版。

　　完成一個release分支

　　當一個release分支準備好成為一個真正的發(fā)行版的時候，有一些工作必須完成。首先，release分支要合并到master上(因為每一次提交到master上的都是一個新定義的發(fā)行版，記住)。然后，提交到master上必須打一個標簽，以便以后更加方便的引用這個歷史版本。后，在release分支上的修改必須合并到develop分支上，以便未來發(fā)行版也包含這些bugs的修復。