GitHub Flow & Git Flow 基於Git 的兩種協做開發模式

介紹基於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.