總結大中小型項目的git流程

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/