1.分支管理
1.1 總覽
從上圖可以看到主要包含下面幾個分支：
master: 主分支，主要用來版本發布。
develop：日常開發分支，該分支正常儲存了開發的最新**。
feature：從develop分支fork，合併回develop。具體的功能開發分支。
release：從develop分支fork，合併回develop和master。一般用於發布正式版本之前(即合併到 master 分支之前)，需要有的預發布的版本進行測試。
hotfix：從master分支fork，合併回develop和master。線上 bug 修復分支。
1.2 主分支(master, develop)
主分支包括 master 分支和 develop 分支。master 分支用來發布，head 就是當前線上的執行**。develop 分支就是我們的日常開發。使用這兩個分支就具有了最簡單的開發模式：develop 分支用來開發功能，開發完成並且測試沒有問題則將 develop 分支的**合併到 master 分支並發布。
1.3 輔助分支(feature , release, hotfix)
feature 分支用來開發具體的功能，一般 fork 自 develop 分支，最終可能會合併到 develop 分支。一般feature分支都存在於開發者本地，開發期間使用git rebase來保證和develop分支的**同步並解決衝突。功能開發完畢後push到遠端倉庫，然後提交pull request，合併到develop分支。
release 分支在我看來是 pre-master。release 分支從 develop 分支 fork 出來，最終會合併到 develop 分支和 master 分支。合併到 master 分支上就是可以發布的**了。有人可能會問那為什麼合併回 develop 分支呢?很簡單，有了 release 分支，那麼相關的**修復就只會在 release 分支上改動了，最後必然要合併到 develop 分支。比如，當開發乙個較長期的feature不著急上線但又需要部署測試時，可以從develop分出乙個release分支，feature提交pull request到這個release分支，然後部署這個release分支到測試服。
hotfix 分支用來修復線上 bug。當線上**出現 bug 時，我們基於 master 分支開乙個 hotfix 分支，修復 bug 之後再將 hotfix 分支合併到 master 分支並進行發布，同時 develop 分支作為最新最全的**分支，hotfix 分支也需要合併到 develop 分支上去。
1.4 分支命名
除了主要分支的名字是固定的之外，派生分支是需要自己命名的，這裡就要有個命名規範了。強烈推薦用如下形式：
master 主分支，發布分支
dev 主分支，開發分支
feat_***——按照功能點(而不是需求)命名;
release_***——用發布時間命名，可以加上適當的字首;
hotfix_***——gitlab 的 issue 編號或 bug 性質等。
小寫字母下劃線形式
1.5 版本號命名
格式為：x.y.z，其中，x 用於有重大重構時才會公升級，y 用於有新的特性發布時才會公升級，z 用於修改了某個 bug 後才會公升級。
v1.1.1：第一位大版本號，大功能發布時增加，技術負責人審核;第二位小版本號，增加小特性時增加，主開發審核;第三位bug修復號，修復bug用，修復人員負責。
每次發布生產(master)，需要為master打乙個tag，方便線上回滾
2.開發規範
2.1 commit原則
只要堅持做到以下幾點就 ok 了：
提交時的粒度是乙個小功能點或者乙個 bug fix，這樣進行恢復等的操作時能夠將「誤傷」減到最低;
用一句簡練的話寫在第一行，然後空一行稍微詳細闡述該提交所增加或修改的地方;
不要每提交一次就推送一次，多積攢幾個提交後一次性推送，這樣可以避免在進行一次提交後發現**中還有小錯誤。
2.2 commit message 格式
(): (不超過50個字)
空 (每行不超過72個字)
空type
feat：新功能(feature)
fix：修補bug
mod：修改(即不是新增功能，也不是修改bug的**變動)
refactor：重構
docs：文件(documentation)
style： 格式(不影響**執行的變動)
test：增加測試
chore：構建過程或輔助工具的變動
scope
用來說明本次commit影響的範圍，即簡要說明修改會涉及的部分。這個本來是選填項，但從angularjs實際專案中可以看出基本上也成了必填項了。
subject
用來簡要描述本次改動，概述就好了，因為後面還會在body裡給出具體資訊。並且最好遵循下面三條:
以動詞開頭，使用第一人稱現在時，比如change，而不是changed或changes
首字母不要大寫
結尾不用句號(.)
body
裡的內容是對上面subject裡內容的展開，在此做更加詳盡的描述，內容裡應該包含修改動機和修改前後的對比。
footer
footer裡的主要放置不相容變更和issue關閉的資訊
revert
此外如果需要撤銷之前的commit，那麼本次commit message中必須以revert：開頭，後面緊跟前面描述的header部分，格式不變。並且，body部分的格式也是固定的，必須要記錄撤銷前commit的sha值。
示例feat: 增加港股經紀商佇列
增加港股經紀商佇列介面和後台名稱編輯介面
增加同時獲取買賣盤和經紀商的介面
breaking change: 刪除了舊版十檔買賣盤介面
git 分支開發規範
git 進行 管理和開發時，分支的管理也是非常必要的 1 master分支 部署生產環境的分支，這個分支只能從其他分支合併，如develop release hotfix，不能在這個分支直接修改 2 develop分支 我們的主開發分支，是乙個穩定的版本，通常由release分支合併過來，通常發到s...
Git分支Git Flow開發規範
規範化管理 庫分支有助於版本庫在演進過程中始終保持簡潔，主幹結構清晰。各個分支各司其職，有利於後續的維護更新，避免版本發布帶來的混亂問題。a successful git branching model git官方文件 branching workflows 以下為git分支開發規範的簡單總結 ma...
git分支管理規範
以下特點是有部分是假設性，部分是實際的 這裡的約束是指無論哪一種場景，以及開發規模大小都必須要遵守的一些git分支管理規則 只需要乙個master分支，然後各自建立自己的分支名為 dev 拼音簡寫 feature fixbug 名稱 如 dev zhang3 userreg,雙發約定好評審方式和me...