團隊專案git分支管理規範:
建立專案時（一般是服務型專案，工具型或輔助型專案可以簡單一些），會針對不同環境建立三個常設分支：
develop：開發環境的穩定分支，公共開發環境基於該分支構建。
pre-release：測試環境的穩定分支，測試環境基於該分支構建。
master：生產環境的穩定分支，生產環境基於該分支構建。僅用來發布新版本，除了從pre-release或生產環境bug修復分支進行merge，不接受任何其它修改
平時開發工作中，會根據需要由開發人員建立兩類臨時分支：
功能（feature）分支：為了開發某個特定功能，從develop分支上面分出來的。開發完成後，要merge到develop分支。功能分支的命名，可以採用feature-*的形式命名(*為任務單號)
bug修復（fixbug）分支：為了修復某個bug，從常設分支上面分出來的。修復完成後，再merge到對應的分支。bug修復分支的命名，可以採用fixbug-*的形式命名（*為bug單號）
從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（即版本號_上線時間）
流程示意圖如下所示
並行開發（即前乙個版本已經轉測但未上線，後乙個版本又已在開發中並部分合併到了develop分支）過程中，轉測後測試環境發現的bug需要修復，但是develop分支此時又有新內容且該部分內容目前不計畫轉測，可以pre-release切出乙個bug修復分支。完成之後需要同時merge到pre-release分支與develop分支。merge時參考「正常開發流程」。
流程示意圖如下
生產環境的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 是乙個開源的分布式版本控制系統，用於敏捷高效地處理任何或小或大的專案。專案中，一般會建立三個常用分支 日常開發中，一般會建立兩類分支 從develop分支切出乙個新分支，根據是功能還是bug，命名為feature 或 fixbug 開發者完成開發，提交分支到遠端倉庫。開發者發起merge請求...
git分支管理規範
以下特點是有部分是假設性，部分是實際的 這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則 只需要乙個master分支，然後各自建立自己的分支名為 dev 拼音簡寫 feature fixbug 名稱 如 dev zhang3 userreg,雙發約定好評審方式和me...