本文首發於我的Github博客
本文介紹了作者瞭解到的三種常見的單倉庫的git工作流，它們是:
- Centralized工作流
- 僅使用master一個分支
- Feature Branch工作流
- 使用一個master分支管理穩定版本
- 使用多個feature分支管理需求開發
- Gitflow工作流
- 使用一個master分支管理髮布版本歷史
- 使用一個develop分支管理開發流程
- 使用多個feature分支管理需求開發
- 使用多個release分支管理版本發佈
- 使用多個hotfix分支修復緊急bug
Centralized工作流
這種工作流只使用唯一的master分支
Centralized需求開發的過程
- 拉取遠端分支(pull/clone)
- 開發(add, commit)
- 上圖中的白色master
- 再次拉取遠端分支(fetch)
- 上圖中的紫色origin/master
- 合入，處理衝突(rebase)
- 上圖中的藍色master
- 注意這裏不使用merge，merge會導致master分支出現類似新branch的分叉行爲, 丟失了單分支的簡潔性
- 提交修改(push)
Centralized工作流優點
- 簡單，對於單人小項目，沒有必要考慮太多管理的情況下直接使用，沒有問題
- 和SVN的工作流非常相似，方便從SVN遷移到Git的團隊做一段時間的緩衝
Centralized工作流缺點
- 太過簡單，沒有利用好Git的分支特性
Feature Branch工作流
對於這種工作流，開發者需要使用:
- 一個master分支管理穩定版本
- 多個feature分支管理需求開發
Feature Branch需求開發的過程
- 拉取遠端分支(pull/clone)
- 從master新建feature分支(checkout -b feature/XXX)
- 開發(add, commit)
- 再次拉取遠端分支(fetch)
- 合入，處理衝突(merge)
- 注意這裏需要的合入處理衝突是指將feature/XXX合入master，而不是將master合入feature/XXX
- 另外，merge的時候建議使用
--no-ff，保證只產生一個merge commit，原因下面會講
- 提交修改(push)
Feature Branch工作流優點
該工作流相比於Centralized工作流，更加複雜，利用了Git分支的特性，相比之下，優點有:
- 需求開發的管理更加清晰，有單獨的分支
- 由於使用的是不同的分支，可以開啓pull request和merge review，通過強制code review提高代碼質量
- 需求分支合入master時，只會產生唯一的merge commit(如果merge的時候使用了
--no-ff的話)，這樣如果想要把一個feature revert掉，只需要revert唯一的一個commit，而不需要選出有關的commit一個個地revert
Feature Branch工作流缺點
缺點/不足:
- 沒有專門用於版本發佈的機制
- 版本發佈可能涉及到很多非開發的雜事(比如文檔編寫與生成，項目打包等等)，這些不適合作爲feature來開發
- 在該工作流中，沒有辦法清晰看出哪些commit是發佈的版本
- 沒有用於緊急修復bug的機制
- 緊急bug修復，也不適合作爲feature來開發
Gitflow工作流
這個工作流需要開發者:
- 使用一個master分支管理髮布版本歷史
- 使用一個develop分支管理開發流程
- 使用多個feature分支管理需求開發
- 使用多個release分支管理版本發佈
- 使用多個hotfix分支修復緊急bug
Gitflow需求開發流程(feature分支)
- 拉取遠端分支(pull/clone)
- 從develop分支開啓新的feature分支(checkout -b feature/XXX)
- 開發(add, commit)
- 再次拉取遠端分支(fetch)
- 合入，解決衝突(merge)
- 提交修改(push)
這個流程和feature branch是一致的，只不過把base分支從master改爲了develop
注意所有的feature分支都:
- 從develop分支新建而來
- 合入到develop分支而去
Gitflow版本發佈流程(release分支)
- 拉取遠端分支(pull/clone)
- 從develop分支開啓新的release分支(checkout -b release/XXX)
- 版本發佈開發(add, commit)
- 包括文檔生成，打包等雜事
- 也可以修復小bug
- 但是大的改動必須使用需求開發流程，去新feature分支進行處理，並移動到下個版本上
- 再次拉取遠端分支(fetch)
- 合入，解決衝突(merge)
- 這裏，需要將release分支同時合入master和develop分支
- 合入master，是爲了保存版本發佈記錄
- 合入develop，是爲了後續開發能夠兼容該版本
- 比如說在release上修復了小bug，或者添加了文檔註釋等，都要反映到後續開發上
- 提交(push)
注意所有的release分支都:
- 從develop分支新建而來
- 合入到master和develop分支而去
Gitflow緊急修復bug流程
- 拉取遠端分支(pull/clone)
- 從master分支新建hotfix分支(checkout -b hotfix/XXX)
- 開發，修復bug(add, commit)
- 再次拉取遠端分支(fetch)
- 合入，解決衝突(merge)
- 這裏的合入需要同時合入master和develop，理由同release分支
- 但是理論上合入master分支的時候不應該有衝突，只能在合入develop分支的時候纔會有可能衝突
- 提交(push)
注意所有的release分支都:
- 從master分支新建而來
- 合入到master和develop分支而去
Gitflow工作流評價
這裏就不放優缺點了，因爲Gitflow是目前使用最廣，最爲流行的git工作流
或許會有一些小的出入，但是各大公司基本上內部都會遵守這樣的規則
大小項目，大小團隊，都適用gitflow工作流