Git flow
最早被提出的分支策略
由兩個主要分支 master, develop 和三個支援性分支 feature, hotfix, release (暫時性)所構成
基本上,
develop 分支會放軟體的最新版本
而 master 分支則是用來放最穩定的版本, 所以軟體要發布正式版本時也會用 master 分支來發布
Feature
在開發的過程中如果要加新功能, 會從 develop 額外拉一條新的 feature 分支出來作新功能, 等功能完成後再合併回 develop 分支裡, 在合併完後 feature 分支會被刪除
Hotfix
當軟體在發佈之後若被發現有 bug, 通常會從 master 分一條 hotfix 分支出來作 bug 修復, 等問題修復完後, 這條 hotfix 分支會被合併到 master 以及 develop 上, 當合併完後也會被刪除
Release
在軟體正式發佈前, 通常會先將軟體預先發布到一個準生產環境中讓 QA 團隊進行測試, 當通過測試之後, release 分支會被刪除
缺點
Gitflow 太複雜了, 有太多的分支需要管理, 不適合對於需要在一天內作多次持續部署的團隊使用
下一篇 淺談三種分支策略 Git flow, GitHub flow, GitLab flow (Part II)
留言
張貼留言