Git 分支管理策略提示詞（Git Flow、GitHub Flow、主幹開發怎麼選 + 團隊分支規範文檔）
團隊要統一分支管理方式、或者現在的分支流程太亂（長期分支合併痛苦、熱修復不知道往哪合）時用：根據團隊規模、發佈頻率和環境數量推薦分支模型，輸出一份包含分支命名、合併規則、發佈與熱修復流程的團隊規範。
通用大模型 對話模型通用
你是一名幫很多團隊落地過研發流程的工程效能顧問。請為我們推薦分支策略並寫出團隊規範。 團隊情況： - 人數與組成：[如 8 個開發、2 個測試] - 發佈頻率：[如每週一次、每天多次、按版本每月一次] - 產品形態：[產品形態]（例：Web 服務持續部署、App 需要應用商店審核、需要同時維護多個版本） - 環境：[如開發、測試、預發、生產] - 代碼託管平台與 CI：[如 GitLab + GitLab CI] - 現在的問題：[如功能分支存活一個月，合併衝突嚴重] 請輸出： 1. 推薦方案：在 Git Flow、GitHub Flow、主幹開發（配合功能開關）、GitLab Flow 等模型中，結合我們的情況推薦一種，說明理由，以及其他方案為什麼不適合。 2. 分支規範： - 長期分支有哪些，各自的作用和保護規則（禁止直接推送、合併需要評審和 CI 通過）； - 短期分支的命名規則（如 feature、fix、hotfix 加問題編號和簡短描述）與存活時間建議； - 合併方式（普通合併、壓縮合並、變基合併）的選擇與理由。 3. 流程（每個流程用編號步驟寫，可以配 Mermaid 圖）： - 日常開發一個功能； - 發佈一個版本（如何打標籤、版本號規則）； - 線上緊急修復，修復如何回到其他分支，避免下次發佈時問題重現； - 如果要同時維護多個版本，修復如何同步到各個版本。 4. 環境與分支的對應關係：哪個分支部署到哪個環境，自動還是手動。 5. 配套：提交資訊規範、合併請求模板的要點、需要在託管平台上開啟的設定。 6. 從現狀遷移到新流程的步驟，以及過渡期的注意事項。 規範部分寫成可以直接放進團隊知識庫的格式。
高亮處換成你自己的內容：[如 8 個開發、2 個測試]、[如每週一次、每天多次、按版本每月一次]、[產品形態]、[如開發、測試、預發、生產]、[如 GitLab + GitLab CI]、[如功能分支存活一個月，合併衝突嚴重]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[發佈頻率] 和 [產品形態] 是選擇分支模型的決定因素。每天多次部署的 Web 服務適合簡單的模型（主幹或 GitHub Flow）；需要應用商店審核、或要同時給不同客戶維護多個版本的產品，才需要發佈分支這類更重的結構。
常見坑：
- 照搬 Git Flow，結果小團隊維護 develop、release、master 多條長期分支，流程繁瑣，合併總出錯。模型的複雜度要和發佈方式匹配。
- 功能分支存活太久（幾週甚至幾個月），合併時衝突巨大。分支越短命越好，大功能可以拆小或者用功能開關先合入主幹。
- 熱修復只合進了生產分支，沒有合回開發分支，下個版本上線後問題又出現了。
追問技巧：追問「把這份規範裏需要在代碼託管平台上配置的項列成清單，並說明在哪裏設定」，或者「寫一個合併請求模板」。
示例輸出
示例，僅供參考（推薦方案節選：10 人團隊，Web 服務每週發佈）
推薦：GitHub Flow 加發布標籤。只有 main 一條長期分支，所有功能通過短期分支合入；每週從 main 打標籤發佈。
| 分支 | 命名示例 | 存活時間 | 規則 |
|---|---|---|---|
| main | main | 長期 | 禁止直接推送；合併需 1 人評審且 CI 通過 |
| 功能 | feature/PROJ-123-coupon-limit | 不超過 3 天 | 壓縮合併到 main |
| 修復 | fix/PROJ-130-price-rounding | 不超過 1 天 | 同上 |
不推薦 Git Flow 的原因：每週發佈、只有一個線上版本，不需要單獨的 develop 和 release 分支，多一層分支只會增加合併成本。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～