git 是乙個開源的分布式版本控制系統，用於敏捷高效地處理任何或小或大的專案。
專案中，一般會建立三個常用分支：
日常開發中，一般會建立兩類分支：
從develop分支切出乙個新分支，根據是功能還是bug，命名為feature-* 或 fixbug-*。
開發者完成開發，提交分支到遠端倉庫。
開發者發起merge請求（可在gitlab頁面「new merge request」），將新分支請求merge到develop分支，並提醒code reviewer進行review
code reviewer對**review之後，若無問題，則接受merge請求，新分支merge到develop分支，同時可刪除新建分支；若有問題，則不能進行merge，可close該請求，同時通知開發者在新分支上進行相應調整。調整完後提交**重複review流程。
轉測時，直接從當前develop分支merge到pre-release分支，重新構建測試環境完成轉測。
測試完成後，從pre-release分支merge到master分支，基於master分支構建生產環境完成上線。並對master分支打tag，tag名可為v1.0.0_2019032115（即版本號_上線時間）
流程示意圖：
並行開發測試環境bug修復流程
並行開發（即前乙個版本已經轉測但未上線，後乙個版本又已在開發中並部分合併到了develop分支）過程中，轉測後測試環境發現的bug需要修復，但是develop分支此時又有新內容且該部分內容目前不計畫轉測，可以pre-release切出乙個bug修復分支。完成之後需要同時merge到pre-release分支與develop分支。merge時參考「正常開發流程」。流程示意圖如下
生產環境bug修復流程
生產環境的bug分兩種情況：
緊急bug：嚴重影響使用者使用的為緊急bug，需立即進行修復。如關鍵業務流程存在問題，影響使用者正常的業務行為。
非緊急bug或優化：非關鍵業務流程問題，僅影響使用者使用體驗，或出現頻率較小等，為非緊急bug，可規劃到後續版本進行修復。
非緊急bug修復參考「正常開發流程」。
緊急bug修復，需要從master分支切出乙個bug修復分支，完成之後需要同時merge到master分支與develop分支（如果需要測試介入驗證，則可先merge到pre-release分支，驗證通過後再merge到master分支上線）。merge時參考「正常開發流程」。流程示意圖如下
專案Git分支管理規範
git 是乙個開源的分布式版本控制系統，用於敏捷高效地處理任何或小或大的專案。專案中，一般會建立三個常用分支 日常開發中，一般會建立兩類分支 從develop分支切出乙個新分支，根據是功能還是bug，命名為feature 或 fixbug 開發者完成開發，提交分支到遠端倉庫。開發者發起merge請求...
git分支管理規範
以下特點是有部分是假設性，部分是實際的 這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則 只需要乙個master分支，然後各自建立自己的分支名為 dev 拼音簡寫 feature fixbug 名稱 如 dev zhang3 userreg,雙發約定好評審方式和me...
git分支管理規範
主分支 master 開發分支 develop 功能分支 feature 修復分支 hotfix 預發布分支 release master 主分支，建立 repository 時缺省會生成乙個 master 分支。通常情況下 master 分支是受保護的 protected master 分支儲存的...