0081. Git - GitFlow 變化 - 多環境分支策略 & 適合的合併方式說明

日期：2024年 12月 28日

標籤： C# Asp.net Core Web MVC Web Git GitHub TortoiseGit

摘要：C# 學習筆記

解決問題：目前 Git策略大多以發布環境搭配合指定分支的方式開發，說明實務上如何規劃
2. 多環境分支策略下適合的合併方式說明
基本介紹：本篇分為二大部分。
第一部分：多環境分支策略
第二部分：4 種合併方式應用說明

第一部分：多環境分支策略

Step 1：本篇分支實作範例

關於GitFlow 分支策略的最初介紹，可以點連結參考
本篇的實作範例:連結

Step 2：多環境分支策略 - 圖

此實作範例，會有以下 Git 分支結構，一種適合多環境部署的 多環境分支策略

Step 3：多環境分支策略 - 優缺點

採用此 Git 多環境分支策略，有以下優缺點

項目	優點	缺點
1. 結構清晰性	- 分支分工明確，角色清晰，容易追蹤功能進展。	- 分支數量多，學習曲線陡峭，對新手不友好。
	- 易於定位問題和回溯歷史。
2. 風險管理	- 隔離性高，功能逐步推進，減少直接影響生產的風險。	- 多層次驗證可能導致流程延遲，增加開發時間。
	- 支持緊急修復流程。
3. 並行開發支持	- 支持多功能分支並行開發，互不影響。	- 多人協作可能導致頻繁的合併衝突。
4. 歷史記錄	- 提交歷史條理清晰，功能變更來源可追溯。	- 頻繁的合併操作可能導致提交歷史變得冗長。
5. 支持 CI/CD	- 支持自動化測試與部署流程。	- 初期工具配置和流程構建成本較高。
6. 效率與成本	- 減少生產風險，增加穩定性。	- 重複驗證和冗長的流程降低開發效率，尤其是小功能時成本不成比例。
7. 適用項目規模	- 適合中大規模團隊和複雜項目。	- 小型團隊和簡單項目中顯得過於複雜，可能不適用。
8. 工具依賴性	- 與工具（如 Jenkins、GitHub Actions）結合可提升效率。	- 手動操作管理分支需要高投入，無工具支持時成本很高。
9. 衝突管理	- 定期同步減少合併衝突風險。	- 多層級分支推進導致合併衝突風險增加，依賴開發者協作能力。
10. 測試與驗證流程	- 確保每個環境的穩定性與可控性。	- 重複測試容易導致人力和時間的浪費，需精準化測試策略。
11. 緊急修復處理	- HotFix 分支可快速修復生產問題，並同步到其他環境。	- 修復後的變更同步流程可能繁瑣，且易出現漏同步的問題。

採用 Git 多環境分支策略考量的點是專案規模的是否夠大，規模較大就很適合使用，便於所有開發統一管理，降低開發合作時的風險性，追朔歷史。

Step 4：多環境分支策略 - 適用場景

延伸到適用環境，列出以下對比

適用場合	不適用場合
1. 中大型團隊（5 人以上）。	- 分小型團隊（1～2 人）。
2. 多環境需求的複雜項目（如開發、測試、預生產、正式生產）。	- 單一環境的簡單應用開發。
3. 功能多，並行開發需求高。	- 短期項目或需求變更較少的項目。
4. 須追蹤歷史和功能來源的長期維護項目。	- 對歷史追蹤要求不高的短期項目。

採用 GitFlow 多環境分支策略考量的點是專案規模的是否夠大，夠大就很適合使用，便於所有開發統一管理，降低開發合作時的風險性。

第二部分：4 種合併方式應用說明

Step 1：前言

可以發現 Git 多環境分支策略是GitFlow 分支策略是延伸變化。
這邊要介紹以下 4 種合併方式 Rebase、Squash、Merge、CherryPick 在此多環境分支策略下，什麼時機點使用

分支	使用方式	情境描述
Feature	Rebase, Squash	Feature 分支與 Dev 同步進展時使用 Rebase，完成後合併到 Dev 使用 Squash 簡化歷史。
Dev	Merge	功能驗證完成後，合併到 QAT 分支，保留完整歷史記錄。
Qat	Merge, Cherry-Pick	合併 Dev 的功能提交；緊急修復從 Dev 挑選變更直接應用到 QAT 進行驗證。
Stage	Merge, Cherry-Pick	合併 QAT 的穩定提交；緊急修復需要挑選特定提交快速應用到 Stage。
Main	Merge, Cherry-Pick	合併 Stage 的穩定提交；Cherry-Pick 應對緊急修復直接上線。