Git Flow
是一種基於 Git 版本控制系統的分支管理模型，定義了一套嚴格的分支命名和操作規範
主要包括以下幾種分支型別：
- 主幹分支（master）：始終保持穩定，只包含經過充分測試和可釋出的程式碼
- 開發分支（develop）：團隊成員在該分支上進行日常的開發工作，所有的新功能和特性都先在這個分支上進行整合和測試
- 特性分支（feature branches）：從develop分支建立，用於開發新的功能或特性，feature/開頭命名
- 釋出分支（release branches）：當開發分支上的功能達到釋出條件時，從develop分支建立釋出分支，用於進行最後的測試和準備釋出工作，release/開頭命名
- 熱修復分支（hotfix branches）：用於緊急修復生產環境中出現的問題，從master分支建立，hotfix/開頭命名。修復完成後，需要同時合併到主幹分支和開發分支
優點：
- 提供了一個清晰、明確的分支管理流程，適合大型團隊和複雜專案的開發，有助於提高團隊協作的效率和程式碼的質量
- 透過不同型別的分支，可以更好地控制程式碼的釋出流程和版本管理，確保生產環境的穩定性和可靠性
缺點：
- 學習成本較高，需要團隊成員熟悉 Git Flow 的各種分支操作和規範，否則容易出現錯誤
- 分支管理相對複雜，可能會導致一些額外的時間和精力消耗在分支的建立、合併和切換等操作上
GitHub Flow
是一種簡化的分支管理策略，主要基於 GitHub 的工作流程。強調頻繁地建立特性分支，開發完成後立即建立拉取請求（Pull Request）進行程式碼審查，審查透過後合併到master分支並進行部署
master分支始終保持可部署狀態，任何時候都可以將master分支上的程式碼部署到生產環境
主要包括以下幾種分支型別：
- 主幹分支（master）：始終保持穩定，只包含經過充分測試和可釋出的程式碼
- 特性分支（feature branches）：從master開發分支建立，用於開發新的功能或特性，feature/開頭命名
- 熱修復分支（hotfix branches）：用於緊急修復生產環境中出現的問題，從master分支建立，hotfix/開頭命名。修復完成後，需要同時合併到主幹分支和開發分支
優點：
- 簡單靈活，易於理解和實施，適合敏捷開發和持續整合/持續部署的工作流程
- 能夠快速地將新功能和改進推向生產環境，促進團隊的快速迭代和創新
缺點：
- 對程式碼審查和自動化測試的要求較高，因為主幹分支的頻繁更新需要確保每次合併的程式碼質量都很高，否則可能會影響生產環境的穩定性
- 在處理複雜的功能開發和多團隊協作時，可能需要更多的協調和溝通，以避免衝突和混亂