本文件旨在規範團隊在 Git Flow 工作流中，如何正確執行版本發佈（Release）流程，以確保代碼穩定性並維持開發節奏。
1. Release 分支的核心用途#
Release 分支是從 develop 到 master 之間的緩衝區，其主要目的為：
- 環境隔離：讓「新功能開發」與「版本穩定化」工作平行運算。
- 最後拋光：進行 Bug 修復、版本號更新（Version Bumping）與文件調整。
- 品質保證：提供一個固定的代碼基準給 QA 團隊進行最終驗證。
2. 命名規範#
建議使用以下格式之一（保持團隊統一即可）：
release/x.y.z(最推薦，符合 SemVer 語意化版本)release/v1.2.0release/2025-Q1(適用於定期發佈)
3. 標準操作流程 (Step-by-Step)#
第一步：建立分支 (Start Release)#
當 develop 已達到預計發佈的狀態：
_10git checkout develop_10git pull origin develop_10git checkout -b release/1.0.0
第二步：穩定化與修復 (Stabilize)#
在此分支進行測試。若發現 Bug，直接在此分支進行修正：
_10# 修正 Bug 後提交_10git add ._10git commit -m "fix: 修正結帳頁面顯示異常"
| Warning |
|---|
| 禁止在此階段合併任何非本次發佈規劃內的新功能。 |
第三步：合併至 Master (Finish Release)#
測試完成後，將代碼合併回主線並標記版本：
_10git checkout master_10git merge --no-ff release/1.0.0_10git tag -a 1.0.0 -m "Release version 1.0.0"
第四步：同步回 Develop (Back-merge)#
重要：確保發佈期間的 Bug 修復能回流到開發線：
_10git checkout develop_10git merge --no-ff release/1.0.0
第五步：清理 (Cleanup)#
刪除本地與遠端的暫存分支：
_10# 刪除本地分支_10git branch -d release/1.0.0_10# 若有推送到遠端則執行：_10git push origin --delete release/1.0.0
4. 常見注意事項 (Best Practices)#
Q: 為什麼不直接在 Develop 分支進行修復？#
A: 在 Develop 分支進行修復可能會引入新的 Bug 或破壞穩定性，Release 分支提供了一個穩定的測試環境。
Q: 如何處理緊急 Bug？#
A: 緊急 Bug 可以優先在 Develop 分支進行修復，但需要特別注意，修復後需要同步回 Release 分支。
Q: 如何處理版本號更新？#
A: 版本號更新應在 Release 分支進行，並同步回 Develop 分支。
-
--no-ff 旗標：合併時務必加上
--no-ff（No Fast-Forward），這能保留分支的歷史線索，方便日後追查。 -
Tag 的重要性：
master上的每一個 Tag 都代表一個可運行的發佈版本，方便隨時回滾。 -
Code Review：在合併回
master與develop前，建議透過 Pull Request (PR) 進行代碼審查。