5月份，為統一團隊git分支管理規範，剛開始準備自己寫，在網上搜了下，發現不少不錯的git分支管理實踐。最後我為團隊選擇了這個git分支管理實踐

A successful Git branching model ，網上有不少參考這篇文章寫的中文版gitflow實踐，推薦一個中文版的Git 最佳實踐：分支管理。

除了團隊git管理的需要，我自己在github上有重要的開源項目采用github flow，這裏轉載一篇關於這兩種分支管理的文章：GitHub Flow & Git Flow 基於Git 的兩種協作開發模式 。

【轉載自】：https://www.cnblogs.com/sloong/p/5868292.html

介紹基於Git 兩種協作開發模式,GitHub Flow & Git Flow

對於Github 一些好用的特殊操作技巧 ，可以見GitHub 特殊操作技巧 和Git的基本操作

一 GitHub Flow

GitHub Flow —— 以部署為中心的開發模式,通過簡單的功能和規則，持續且高速 安全地進行部署。在實際開發中往往一天之內會實施幾十次部署，而支撐這一切的，就是足夠簡單的開發流程以及完全的自動化。

GitHub Flow 特點：

1. 令master 分支時常保持可以部署的狀態
2. 進行新的作業時要從master 分支創建新的分支，新分支名稱要具有描述性
3. 在2新建的本地倉庫分支中進行提交
4. 在Github 端倉庫創建同名分支，定期push
5. 需要幫助、反饋，或者branch已經準備merging時，創建Pull Request，以Pull Request 進行交流
6. 讓其他開發者進行審查，確認作業完成後與master分支進行合並（合並的代碼一定要測試
7. 與master分支合並後，立刻部署

使用Github Flow 的前提條件：

• 團隊規模最好控制在15-20人之內，具體見 how-github-works
• 部署作業完全自動化。必須自動化，一天之類需要多次部署
  • 使用部署工具（Capistrano，Mina，Fabric,Webistrano,Strano等），讓部署時所需的一系列流程自動化。
  • 通過Web界面進行部署，Capistrano 等部署工具需要命令執行操作，開發者以外的人很難實施部署
    • Capistrano http://github.com/capistrano/capistrano //Ruby開發的代表性部署工具
    • Webistrano http://kentaro/webistrano //可以通過Web執行Capistrano的工具
  • 導入開發時註意事項：隨著團隊人數的增多及成熟度的提高，開發速度會越來越快。往往一個部署尚未完成，另一名開發者就已經處理完下一個pull request，開始實施下一個部署。在這種情況下，一旦正式環境出現問題，很難分辨哪個部署造成了影響。為了應對該情況，建議在部署實施過程中通過工具加鎖。
  • Git Hook 自動部署
• 重視測試
  • 讓測試自動化
  • 編寫測試代碼，通過全部測試
  • 維護測試代碼

二 Git Flow

荷蘭程序員 Vincent Driessen 曾發表了一篇博客，讓一個分支策略廣為人知。具體流程見下圖（引用該博客的一幅圖片）

這一流程最大的亮點是考慮了緊急Bug的應對措施，整個流程顯得過於復雜，所以在實施該方案前，需要對整個開發流程進行系統的學習。也需要借助Git flow 等工具的輔助。

下面根據上圖，按不同分支 進行 說明：

master 分支和 develop分支

在Git Flow 中，這兩個分支至關重要，它們會貫徹整個流程始終，絕對不會被刪除。

master 分支

master 分支時常保持著軟件可以正常運行的狀態。由於要維護這一狀態，所以不允許開發者直接對master 分支的代碼進行修改和提交。

其他分支的開發工作進展到可以發布的程度後，將會與master分支進行合並，並且這一合並只在發布成品時進行。發布時將會附加版本編號的Git標簽。

develop分支

develop分支是開發過程中代碼中心分支。與master 分支一樣，這個分支也不允許開發者直接進行修改和提交。

程序員要以develop分支為起點新建feature 分支，在feature 分支中進行新功能的開發或者代碼的修正。也就是說develop分支維系著開發過程中的最新代碼，以便程序員創建feature分支進行自己的工作。

在feature 中工作

feature 分支以develop分支為起點，是開發者直接更改代碼發送提交的分支。開發流程：

1. 從develop分支創建feature分支
2. 從feature分支中實現目標功能
3. 通過Github 向develop發送pull request
4. 接受其他開發者審核後，將Pull Request合並至develop分支

具體指令：

$ git checkout develop
$ git pull
$ git flow feature start add-user //add branch feature/add-user
$ git branch
// feature/add user  start commit commit ....
$ git push orgin feature/add-user
//到github 上去代碼審查，切到develop分支，進行pull request 
$ git checkout develop
$ git pull // 當feature/add-user 合並到 develop後，本地develop 需要更新到最新狀態

註意，默認狀態是pull request 到master。這時需要手動切換到develop分支，再進行pull Request 操作。
如果采用該開發策略，那麽可以在setting 中 Option 中，修改Default Branch 為 develop ，這樣就省去了手動修改的麻煩。

與develop分支合並後，已經完成工作的feature分支可以在適當的時機刪除

更新本地的develop分支

我們發送的pull request 在github 端與develop 合並後，為了讓其反應到本地的develop分支中，我們需要進行以下操作：

• 切換到develop分支
• 執行git pull (fetch & merge)

每當需要從develop分支創建feature等分支時，記得一定要先執行上述操作，保證develop分支處於最新狀態。

release分支

創建 release分支 ，在這個分支，我們只處理與發布前準備相關的提交，比如版本編號變更的元數據的添加工作。如果軟件部署到預演環境後測試出bug，相關修正也要提交到這個分支。

註意：該分支絕對不能包含需求變更或者功能變更等重大修正。這一階段的提交數應該限制到最低。

$ git checkout develop
$ git pull
$ git flow release start ‘1.0.0‘

當所有修正處理完後，我們結束這分支

$ git flow release finish ‘1.0.0‘
//期間會需要填寫 提交信息、這個版本的提交信息、合並的提交信息。無特殊情況，一般默認。

全部結束後，會顯示如下

$ git flow release finish ‘1.0.0‘
Switched to branch ‘master‘
Your branch is up-to-date with ‘origin/master‘.
Merge made by the ‘recursive‘ strategy.
 README.md | 2 ++
 1 file changed, 2 insertions(+)
Switched to branch ‘develop‘
Your branch is up-to-date with ‘origin/develop‘.
Already up-to-date!
Merge made by the ‘recursive‘ strategy.
Deleted branch release/1.0.0 (was d3f54a0).

Summary of actions:
- Release branch ‘release/1.0.0‘ has been merged into ‘master‘
- The release was tagged ‘1.0.0‘
- Release tag ‘1.0.0‘ has been back-merged into ‘develop‘
- Release branch ‘release/1.0.0‘ has been locally deleted
- You are now on branch ‘develop‘

查看版本tag

通過前面一系列的操作，我們創建了與發布版本號相同的Git標簽

$ git tag
1.0.0

更新到遠程倉庫

對此，我們對多個分支進行了修改，所以需要利用push操作將修改更新到Github端的遠程倉庫。先從develop開始

$ git push origin develop

然後是master

$ git checkout master
$ git push origin master

再push 標簽信息

$ git push --tags

這樣版本號 1.0.0 的標簽信息就已經push 完成

在hotfix 分支下進行工作

下述情況需要創建 hotfix 分支

• release 版本中發現了bug 或者漏洞
• develop 分支正在開發新功能，無法面向用戶進行發布
• 漏洞需要及早處理，無法等到下一次版本發布

假設修復BUG 後的版本至 1.0.1

$ git fetch origin

現在以1.0.0的標簽信息為起點，創建名為1.0.1 的hotfix分支。

$ git flow hotfix start ‘1.0.1‘ ‘1.0.0‘

修復工作結束後，將hotfix 分支push 到github端的遠程倉庫，並向master分支發起Pull Request

$ git push origin hotfix/1.0.1

創建標簽和進行發布

在Github項目主頁，點擊release ，為本次hotfix 創建1.0.1標簽。點擊 Draft a new release 按鈕，輸入相關標簽信息，在Target中指定master分支（master分支已經合並了hotfix1.0.1的修改）。然後填寫相關信息，點擊Publish release 進行發布

1.0.1發布後，之前發布的成品也就完成了生命周期

$ git fetch origin

從 hotfix 分支合並到develop 分支

登錄到Github，從hotfix1.0.1分支向develop分支發送Pull Request即可。審查後便會被合並到develop分支

Git Flow 的小結

建議把開發流程圖放大貼在墻上，這樣能夠有效幫助團隊成員理解流程內容

版本號的分配規則 x.y.z

x: 在重大功能變更，或者版本不向下兼容+1，此時y z歸零
y: 在添加新功能或者刪除已有功能+1 此時z歸零
z: 只在進行內部修改後+1.

Git 最佳實踐：分支管理