gitFlow工做流程

Git主要優勢有

分佈式存儲 , 本地倉庫包含了遠程倉庫的全部內容 . 安全性高 , 遠程倉庫文件丟失了也不怕
優秀的分支模型 , 建立/合併分支很是的方便
方便快速 , 因爲代碼本地都有存儲 , 因此從遠程拉取和分支合併時都很是快捷
當分支過多時 , 如何管理這些分支呢 ? 咱們團隊採用了Git Flow的模式

GitFlow的經常使用分支

master
主分支 , 產品的功能所有實現後 , 最終在master分支對外發布
該分支爲只讀惟一分支 , 只能從其餘分支(release/hotfix)合併 , 不能在此分支修改
另外全部在master分支的推送應該打標籤作記錄,方便追溯
例如release合併到master , 或hotfix合併到master
develop
主開發分支 , 基於master分支克隆
包含全部要發佈到下一個release的代碼
該分支爲只讀惟一分支 , 只能從其餘分支合併
feature功能分支完成 , 合併到develop(不推送)
develop拉取release分支 , 提測
release/hotfix 分支上線完畢 , 合併到develop並推送
feature
功能開發分支 , 基於develop分支克隆 , 主要用於新需求新功能的開發
功能開發完畢後合到develop分支(未正式上線以前不推送到遠程中央倉庫!!!)
feature分支可同時存在多個 , 用於團隊中多個功能同時開發 , 屬於臨時分支 , 功能完成後可選刪除
release
測試分支 , 基於feature分支合併到develop以後 , 從develop分支克隆
主要用於提交給測試人員進行功能測試 , 測試過程當中發現的BUG在本分支進行修復 , 修復完成上線後合併到develop/master分支並推送(完成功能) , 打Tag
屬於臨時分支 , 功能上線後可選刪除
hotfix
補丁分支 , 基於master分支克隆 , 主要用於對線上的版本進行BUG修復
修復完畢後合併到develop/master分支並推送 , 打Tag
屬於臨時分支 , 補丁修復上線後可選刪除
全部hotfix分支的修改會進入到下一個release

主要工做流程

1 . 初始化項目爲gitflow , 默認建立master分支 , 而後從master拉取第一個develop分支

2 . 從develop拉取feature分支進行編碼開發(多個開發人員拉取多個feature同時進行並行開發 , 互不影響)

3 . feature分支完成後 , 合併到develop(不推送 , feature功能完成還未提測 , 推送後會影響其餘功能分支的開發)

合併feature到develop , 能夠選擇刪除當前feature , 也能夠不刪除 . 但當前feature就不可更改了 , 必須從release分支繼續編碼修改

4 . 從develop拉取release分支進行提測 , 提測過程當中在release分支上修改BUG

5 . release分支上線後 , 合併release分支到develop/master並推送

合併以後 , 可選刪除當前release分支 , 若不刪除 , 則當前release不可修改 . 線上有問題也必須從master拉取hotfix分支進行修改

6 . 上線以後若發現線上BUG , 從master拉取hotfix進行BUG修改

7 . hotfix經過測試上線後 , 合併hotfix分支到develop/master並推送

合併以後 , 可選刪除當前hostfix , 若不刪除 , 則當前hotfix不可修改 , 若補丁未修復 , 須要從master拉取新的hotfix繼續修改

8 . 當進行一個feature時 , 若develop分支有變更 , 如其餘開發人員完成功能並上線 , 則須要將完成的功能合併到本身分支上

即合併develop到當前feature分支

9 . 當進行一個release分支時 , 若develop分支有變更 , 如其餘開發人員完成功能並上線 , 則須要將完成的功能合併到本身分支上

即合併develop到當前release分支 (!!! 由於當前release分支經過測試後會發佈到線上 , 若是不合並最新的develop分支 , 就會發生丟代碼的狀況)