使用Git Flow管理開發流程
我們都知道, 在 git 的分支功能相對 svn 確實方便許多，而且也非常推薦使用分支來做開發. 我的做法是每個項目都有2個分支, master 和 develop. master 分支是主分支, 保證程序有一個 穩定版本, develop 則是開發用的分支, 幾乎所有的功能開發, bug 修復都在這個分支上, 完成後 再合併回 master.
但是情況並不是這麼簡單. 有時當我們正在開發一個功能, 但程序突然出現 bug 需要及時去修復的時候, 這時要切回 master 分支, 並基於它創建一個 hotfix 分支. 有時我們在開發一個功能時, 需要停下來去開發另一個功能. 而且所有這些問題都出現 的時候, 發布也會成為比較棘手問題.
也就是說, git branch 功能很強大，但是沒有一套模型告訴我們應該怎樣在開發的時候善用 這些分支。於是有人就整理出了一套比較好的方案 A successful Git branching model, 今天我們就一起來學習下這套方案.
簡單來說, 他將 branch 分成2個主要分支和3個臨時的輔助分支:
主要分支
master: 永遠處在即將發布(production-ready)狀態
develop: 最新的開發狀態
輔助分支
feature: 開發新功能的分支, 基於 develop, 完成後 merge 回 develop
release: 準備要發布版本的分支, 用來修復 bug. 基於 develop, 完成後 merge 回 develop 和 master
hotfix: 修復 master 上的問題, 等不及 release 版本就必須馬上上線. 基於 master, 完成後 merge 回 master 和 develop
作者還提供了 git-flow 命令工具:
$ git flow init
接著它會問你一系列的問題，蛋定！盡量使用它的默認值就好了：
No branches exist yet. Base branches must be created now.Branch name for production releases: [master]Branch name for "next release" development: [develop]How to name your supporting branch prefixes?Feature branches? [feature/]Release branches? [release/]Hotfix branches? [hotfix/]Support branches? [support/]Version tag prefix? []
完成後當前所在分支就變成 develop. 任何開發都必須從 develop 開始:
git flow feature start some_awesome_feature
完成功能開發之後:
git flow feature finish some_awesome_feature
該命令將會把feature/some_awesome_feature合併到develope分支，然後刪除功能(feature)分支。
將一個 feature 分支推到遠程伺服器:
git flow feature publish some_awesome_feature或者git push origin feature/some_awesome_feature
當你的功能點都完成時（需要發布新版本了），就基於develop創建一個發布(release)分支，然後升級版本號並在最後發布日期前把Bug Fix掉吧：
$ git flow release start v0.1.0
當你在完成（finish)一個發布分支時，它會把你所作的修改合併到master分支，同時合併回develop分支，所以，你不需要擔心你的master分支比develop分支更加超前。
最後一件讓git-flow顯得威武的事情是它處理熱修復（即時的BugFix）的能力，你可以像其他分支一樣地創建和完成一個熱修復分支，區別是它基於master分支，因此你可以在產品出現問題時快速修復，然後通過」finish」命令把修改合併回master和develop分支。
git flow on github: https://github.com/nvie/gitflow
推薦閱讀：