套裝軟體專案的 Git 分支管理實務分享

在多人協作的 Git 專案中，如何設計清晰的分支管理流程，往往直接影響到開發效率與產品穩定性。這篇文章分享我們公司在實務上採用的「四分支策略」，搭配出貨與雲端部署的實際情境，供大家參考。

🎯 我們的四大分支角色

分支名稱	用途	對象	備註
`dev`	日常開發	RD	功能開發、debug 都在這裡進行
`test`	測試驗證	QC	開發完成後合併到此，由 QA 進行測試
`main`	對外穩定版	PM / 客戶	通過測試後合併進來，作為候選正式版本
`cloud`	雲端部署用	DevOps	從穩定 `main` 分支產出，搭配雲端設定進行部署

🔄 實際開發流程

RD 在 dev 分支開發功能
所有功能分支從 dev 分出，開發完成後 PR 回 dev。
定期將 dev 合併進 test，交由 QC 測試
測試團隊在 test 分支上驗證功能是否符合規格。
測試通過後 PR 合併進 main，作為出貨候選版本
main 為準穩定版本，可能會交給客戶、PM 試用或出貨。
當 main 經實際運行一段時間確認穩定後
→ 從 main 分出 cloud 分支，進行雲端版本的專屬部署。

☁️ 為什麼還要有 `cloud` 分支？

很多人會問：都已經有 main 了，為什麼還要分出 cloud？

因為我們的雲端版本是提供給 多個客戶共用的租賃版本（SaaS 模式），一旦上線後出現問題，影響的就不只是單一客戶，而是整批用戶，會直接導致大量客服回報與信任危機。

因此我們採用以下做法來確保雲端部署的穩定性：

cloud 是實際部署到雲端環境的版本，必須 絕對穩定且經實戰驗證。
cloud 分支源自 main，只會在 main 經過一段時間運行、確認穩定後才分出。
cloud 可能會包含特定於雲端環境的設定與部署配置。
使用獨立的 cloud 分支，也讓我們能針對雲端部署做精細控制，而不干擾到一般客戶的出貨流程。

換句話說，cloud 是從 main 精選出的 最終穩定版本，再加上雲端專用設定，確保對大量租戶的交付品質。

✅ 這樣設計的好處

明確區分開發、測試、出貨、部署等不同階段。
減少主幹污染與出貨風險。
讓各角色（RD、QC、PM、DevOps）都有清晰的作業目標。
保留每個版本的可回溯歷史，方便維運與除錯。

🧩 總結

這套四分支策略讓我們的開發與部署流程更有條理，不再手忙腳亂：

dev → test → main → cloud

這不只是一套分支規則，更是一種團隊協作的共識與節奏。

你也可以依照自己的團隊規模與工作流程做出調整。如果你也有不同的 Git 流程設計，也歡迎留言交流！