git作為源碼管理工具出於流行趨勢。這里和大家一起分享下我們是如何用git的分支(branch)功能管理不同規模的項目
小型項目
推薦工具：TortoiseGit
開發階段（第一版上線前）：2個分支 develop和master
由於是項目參與人員不多,基本上很少會有不同角色的人員出現職責沖突，需求變更也不會很繁冗。這種情況值我們只需要主要功能分支。
其中develop負責開發版本，master相當於預上線版本。
develop過程如果出現代碼沖突，手工merge就好。
開發階段（第一版上線后）：3個分支 develop、master、hotfix
多處於來的hotfix用於緊急上線（bug，新需求等）。hotfix基於master，因為develop已經越走越遠，基於develop的hotfix會將帶上一些當前不想上線的新功能。
hotfix完成后hotfix要merge到master上，因為線上不管何種情況都是master版本。qa完成測試並且上線后要將master版本merge到develop避免hotfix的修改在develop中丟失。
維護階段(停止常規開發)：2個分支 master、hotfix。
這個階段就相當於針對上線版本的各種打補丁了。
中型項目
推薦工具： sourcetree
開發階段（第一版上線前）：3個分支 feature、develop和master
相對於小型項目多了feature分支的概念。feature分支基於develop分支，當功能開發完成后merge回develop。
這樣做的好處是將develop分支從小型項目中去中心化。舉個例子，因為是中型項目，我們可能有5 6個在並行開發，如果這個過程中客戶說某個功能我們不要了，我們可以很輕松的丟掉某個feature分支而不必污染develop。
但是如果是開發時間很久的feature分支，很可能會因為不定時的merge develop或者需求的不斷變更等導致當前分支的commit比較骯臟。所以對於feature分析的力度要控制好。
如圖所示：
開發階段（第一版上線后）：4個分支 feature、develop、master和hotfix
和上面小心項目一樣 hotfix基於master版本。
維護階段(停止常規開發)： 和小型項目一樣
大型項目
推薦工具：sourcetree
大型項目相對於中型項目又多了release版本。這個版本的作用只要是控制需求的更新以及當前版本bug的fix處理。
點擊查看大圖：
對於這種情景sourcetree自帶git-flow的功能
並且給出各種引導提示
和中型項目相比，hotfix分支在大型項目中只處理線上的bug問題。對於需求的控制，都會發生在release分支中。一個release版本的生成並不意味着它可以直接提交master，qa的介入在中小型項目中屬於master分支，
但是在這個流程下，qa的介入屬於release分支，包括對於bug的修復操作也是直接在release版本完成。當qa對於release版本確認完成后，release版本merge到master預上線並且merge回develop保持代碼一致性。
更詳細的資料可以參考： http://nvie.com/posts/a-successful-git-branching-model/