# 套裝軟體專案的 Git 分支管理實務分享 在多人協作的 Git 專案中，**如何設計清晰的分支管理流程**，往往直接影響到開發效率與產品穩定性。這篇文章分享我們公司在實務上採用的「四分支策略」，搭配出貨與雲端部署的實際情境，供大家參考。 --- ## 🎯 我們的四大分支角色 | 分支名稱 | 用途 | 對象 | 備註 | |----------|------|------|------| | `dev` | 日常開發 | RD | 功能開發、debug 都在這裡進行 | | `test` | 測試驗證 | QC | 開發完成後合併到此，由 QA 進行測試 | | `main` | 對外穩定版 | PM / 客戶 | 通過測試後合併進來，作為候選正式版本 | | `cloud` | 雲端部署用 | DevOps | 從穩定 `main` 分支產出，搭配雲端設定進行部署 | --- ## 🔄 實際開發流程 1. **RD 在 `dev` 分支開發功能** 所有功能分支從 `dev` 分出，開發完成後 PR 回 `dev`。 2. **定期將 `dev` 合併進 `test`，交由 QC 測試** 測試團隊在 `test` 分支上驗證功能是否符合規格。 3. **測試通過後 PR 合併進 `main`，作為出貨候選版本** `main` 為準穩定版本，可能會交給客戶、PM 試用或出貨。 4. **當 `main` 經實際運行一段時間確認穩定後** → **從 `main` 分出 `cloud` 分支**，進行雲端版本的專屬部署。 --- ## ☁️ 為什麼還要有 `cloud` 分支？ 很多人會問：**都已經有 `main` 了，為什麼還要分出 `cloud`？** 因為我們的雲端版本是提供給 **多個客戶共用的租賃版本（SaaS 模式）**，一旦上線後出現問題，影響的就不只是單一客戶，而是整批用戶，會直接導致大量客服回報與信任危機。 因此我們採用以下做法來確保雲端部署的穩定性： - `cloud` 是實際部署到雲端環境的版本，必須 **絕對穩定且經實戰驗證**。 - `cloud` 分支源自 `main`，只會在 `main` 經過一段時間運行、確認穩定後才分出。 - `cloud` 可能會包含特定於雲端環境的設定與部署配置。 - 使用獨立的 `cloud` 分支，也讓我們能針對雲端部署做精細控制，而不干擾到一般客戶的出貨流程。 換句話說，`cloud` 是從 `main` 精選出的 **最終穩定版本**，再加上雲端專用設定，確保對大量租戶的交付品質。 --- ## ✅ 這樣設計的好處 - 明確區分開發、測試、出貨、部署等不同階段。 - 減少主幹污染與出貨風險。 - 讓各角色（RD、QC、PM、DevOps）都有清晰的作業目標。 - 保留每個版本的可回溯歷史，方便維運與除錯。 --- ## 🧩 總結 這套四分支策略讓我們的開發與部署流程更有條理，不再手忙腳亂： ``` dev → test → main → cloud ``` 這不只是一套分支規則，更是一種**團隊協作的共識與節奏**。 --- 你也可以依照自己的團隊規模與工作流程做出調整。如果你也有不同的 Git 流程設計，也歡迎留言交流！ ---