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保持代碼一致性。