基本**分支應該分為兩類，一類是主要分支，包括線上主分支 master 和開發主分支
develop；另一類是輔助分支，包括測試分支 release，線上緊急修復分支 hotfix，以及功能
開發分支 feature。
● master 分支上的所有**節點都必須處於可發布狀態，且與線上執行的版本對應並且每乙個
節點都生成了 tag 標註了發布的版本 id。
● develop 分支上的**節點代表了最新的功能開發進度，用於日常的功能開發，整合了多個新
開發的功能以及正式提測前的 bug 修復**。
● feature 分支用於管理功能的並行開發（命名建議為」feature-*」） ，起源於 develop 分支，最終
也會歸於 develop 分支（要求採用--no-ff 的方式進行分支合併，以確保整個提交鏈的完整
性） 。
● release 分支主要用於正式的測試並幫助構建可發布的**（命名建議為」release-*」） ，起源於
develop 分支，最終歸於「develop」及「master」分支。正式提測後的 bug 修復必須在此分支上進
行，並且需盡量避免新功能的併入。每次當 release **合併到 master 分支時都必須反向合
並回 develop 分支。
● hotfix 分支用於緊急修復線上執行版本的關鍵 bug（命名建議為」hotfix-*」） ，hotfix 分支基於
master 分支建立，開發完後需要合併回 master、release 和 develop 分支，同時在 master
上打乙個 tag。
release 和 master 分支須受到保護，必須有固定的一到兩名人員負責分支的合併操作。
提測規範
● 持續整合應用接入 qa 環境需根據線上最新版本**做一次初始化
● 每次提交**都需正確填寫備註（功能描述） ，每次發版都要打 tag 標籤
● 提測期間有問題，基於 release 分支修改，測試通過後基於 release 發布
● 線上緊急 bug從 master 拉 hotfix 分支修改，合併至 master 發版修復
● sa 組除 hotfix 外的發版均基於提測通過的 release 分支
**管理準則
● 建立分支要有計畫性，盡可能的控制分支的數量
● 低版本總是積極的合併到高版本，同時注意反向合併
● 每次提交及合併的日誌須完整規範，說明修改部分的意圖
● 發起合併的版本務必經過冒煙自測及**評審
● 珍惜每次提測，提測內容與修改內容相符
提交note:
[sixing/fix/add/modify][model/bug/iteration]func
Git分支 master分支和開發版本分支
問題 在使用git時，假如遠端倉庫有dev和master兩個分支，master作為乙個穩定版分支，可用於直接發布產品，日常的開發則push到dev分支，那本地是不是要從dev分支中建立乙個本地分支，然後在這個分支的push的動作是預設推到遠端dev分支上？解惑 一 遠端倉庫有master和dev分支...
git分支管理規範
以下特點是有部分是假設性，部分是實際的 這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則 只需要乙個master分支，然後各自建立自己的分支名為 dev 拼音簡寫 feature fixbug 名稱 如 dev zhang3 userreg,雙發約定好評審方式和me...
Git分支命名規範
分支 命名說明 主分支master 主分支，所有提供給使用者使用的正式版本，都在這個主分支上發布 開發主分支 dev開發分支，永遠是功能最新最全的分支 功能分支 feature 新功能分支，某個功能點正在開發階段 發布版本 release 發布定期要上線的功能 修 布版本分支 bugfix rele...