Git 工做流程

團隊多人協做，必需要有一個適合團隊的，規範的工做流程

協做必須有一個規範的工做流程，讓你們有效地合做，使得項目層次分明地發展下去。"工做流程"在英語裏，叫作"workflow"或者"flow"，原意是水流，比喻項目像水流那樣，順暢、天然地向前流動，不會發生衝擊、對撞、甚至漩渦。

市面上主要有3中工做流Git flow，Github flow，Gitlab flow。這裏咱們採用Git flow工做流。

下面具體介紹該工做流

主要特色

首先，項目存在兩個長期分支。

• 主分支master
• 開發分支develop
  前者用於存放對外發布的版本，任什麼時候候在這個分支拿到的，都是穩定的分佈版；後者用於平常開發，存放最新的開發版。
  （兩個長期分支）

其次，項目存在三種短時間分支。

• 功能分支（feature branch）
• 補丁分支（hotfix branch）
• 預發分支（release branch）（可用我的開發分支替代）

平常開發

• 建立我的開發分支，基於遠程 dev 建立

  git checkout -b feature-a origin/dev

• 同步 dev 分支

  git rebase origin/dev

• 完成開發，commit，push 遠程。
• 發起合入 dev 分支請求（使用 gitlab 新建合併請求）
• 管理者接受合併請求，代碼合併進入 dev 分支。

預發佈版本測試、正式發版

• 建立預發佈分支（如：release-1.0.0），基於 dev 分支建立預發佈分支
• 測試預發佈分支代碼
• 測試經過後，合入 master 分支
• 正式發佈版本，打版本 tag

bug 修復

預發佈版本 bug 修復

• 建立bug分支，基於預發佈版本分支建立。（假設預發佈版本分支爲：release-1.0.0）

  git checkout -b 15-release-1.0.0-bug-a origin/release-1.0.0

  建議 bug 分支命名規範：與 issue 的名字保持一致，而且以issue的編號起首。如"15-release-1.0.0-bug-a "。
  開發完成後，在提交說明裏面，能夠寫上"fixes #14"或者"closes #67"。Gitlab 規定，只要commit message裏面有下面這些動詞 + 編號，就會關閉對應的issue。
  如未建立 issue，去掉頭部的編號。

• 完成修復 bug ，本地提交（commit），push 遠程。
• 發起合入預發佈版本分支（使用 gitlab 新建合併請求）。

• 發起合入 dev 分支（使用 gitlab 新建合併請求）。

  注意：bug 修復完成後，同時須要合入 dev 分支

• 管理者接受合併請求，代碼合入目標分支。

master（線上） bug 修復

流程同 "預發佈版本 bug 修復" 流程

區別在於

• 建立分支是基於 master 分支建立
• 分支名爲 15-master-1.0.0-bug-a
• bug 修復完成後，發起合入 master 分支和 dev 分支。

參考：
Git 工做流程
Git分支管理策略