熬夜的蟲子

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/