Git 最佳實踐：分支管理

      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.

標籤：其他

上一篇：（四）版本控制管理器之VSS

下一篇：JIRA筆記（一）：安裝部署JIRA