【過程改進(jìn)】總結(jié)大中小型項(xiàng)目的git流程
git作為源碼管理工具出于流行趨勢。這里和大家一起分享下我們是如何用git的分支(branch)功能管理不同規(guī)模的項(xiàng)目
小型項(xiàng)目
推薦工具:TortoiseGit
開發(fā)階段(第一版上線前):2個分支 develop和master
由于是項(xiàng)目參與人員不多,基本上很少會有不同角色的人員出現(xiàn)職責(zé)沖突,需求變更也不會很繁冗。這種情況值我們只需要主要功能分支。
其中develop負(fù)責(zé)開發(fā)版本,master相當(dāng)于預(yù)上線版本。
develop過程如果出現(xiàn)代碼沖突,手工merge就好。
開發(fā)階段(第一版上線后):3個分支 develop、master、hotfix
多處于來的hotfix用于緊急上線(bug,新需求等)。hotfix基于master,因?yàn)閐evelop已經(jīng)越走越遠(yuǎn),基于develop的hotfix會將帶上一些當(dāng)前不想上線的新功能。
hotfix完成后hotfix要merge到master上,因?yàn)榫€上不管何種情況都是master版本。qa完成測試并且上線后要將master版本merge到develop避免hotfix的修改在develop中丟失。
維護(hù)階段(停止常規(guī)開發(fā)):2個分支 master、hotfix。
這個階段就相當(dāng)于針對上線版本的各種打補(bǔ)丁了。
中型項(xiàng)目
推薦工具: sourcetree
開發(fā)階段(第一版上線前):3個分支 feature、develop和master
相對于小型項(xiàng)目多了feature分支的概念。feature分支基于develop分支,當(dāng)功能開發(fā)完成后merge回develop。
這樣做的好處是將develop分支從小型項(xiàng)目中去中心化。舉個例子,因?yàn)槭侵行晚?xiàng)目,我們可能有5 6個在并行開發(fā),如果這個過程中客戶說某個功能我們不要了,我們可以很輕松的丟掉某個feature分支而不必污染develop。
但是如果是開發(fā)時間很久的feature分支,很可能會因?yàn)椴欢〞r的merge develop或者需求的不斷變更等導(dǎo)致當(dāng)前分支的commit比較骯臟。所以對于feature分析的力度要控制好。
如圖所示:
開發(fā)階段(第一版上線后):4個分支 feature、develop、master和hotfix
和上面小心項(xiàng)目一樣 hotfix基于master版本。
維護(hù)階段(停止常規(guī)開發(fā)): 和小型項(xiàng)目一樣 大型項(xiàng)目
推薦工具:sourcetree
大型項(xiàng)目相對于中型項(xiàng)目又多了release版本。這個版本的作用只要是控制需求的更新以及當(dāng)前版本bug的fix處理。
點(diǎn)擊查看大圖:
對于這種情景sourcetree自帶git-flow的功能
并且給出各種引導(dǎo)提示
和中型項(xiàng)目相比,hotfix分支在大型項(xiàng)目中只處理線上的bug問題。對于需求的控制,都會發(fā)生在release分支中。一個release版本的生成并不意味著它可以直接提交master,qa的介入在中小型項(xiàng)目中屬于master分支,
但是在這個流程下,qa的介入屬于release分支,包括對于bug的修復(fù)操作也是直接在release版本完成。當(dāng)qa對于release版本確認(rèn)完成后,release版本merge到master預(yù)上線并且merge回develop保持代碼一致性。
posted on 2014-07-15 10:24 順其自然EVO 閱讀(171) 評論(0) 編輯 收藏 所屬分類: 測試學(xué)習(xí)專欄