? ? ? 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?特點：

令master 分支時常保持可以部署的狀態

進行新的作業時要從master 分支創建新的分支，新分支名稱要具有描述性

在2新建的本地倉庫分支中進行提交

在Github 端倉庫創建同名分支，定期push

需要幫助、反饋，或者branch已經準備merging時，創建Pull Request，以Pull Request 進行交流

讓其他開發者進行審查，確認作業完成后與master分支進行合并（合并的代碼一定要測試

與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分支為起點，是開發者直接更改代碼發送提交的分支。開發流程：

從develop分支創建feature分支

從feature分支中實現目標功能

通過Github 向develop發送pull request

接受其他開發者審核后，將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.

?

作者：Bwar 出處：https://www.cnblogs.com/bwar/

Bwar傾力打造的高性能網絡框架Nebula：https://github.com/Bwar/Nebula

原創文章如轉載，請注明出處。本文首發于博客園。

總結

以上是生活随笔為你收集整理的Git 最佳实践：分支管理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。