完整Git版本管理策略詳情 - git,版本,管理,建議,合作 vistart 動態日志

策略概述

本文檔提供了一套全面的Git版本管理策略，旨在處理多個併發版本，同時保持代碼質量和團隊生產力。

重要提示：本策略作為框架和建議集合而非嚴格規則。團隊應根據以下因素調整這些指導原則：

項目規模和複雜性
團隊規模和經驗水平
業務需求和約束
技術棧和生態系統慣例
組織政策和合規要求

本策略特別適合：

需要長期維護多個版本的項目
同時開發應用程序和框架/庫軟件的團隊
需要在開發速度與穩定性之間取得平衡的組織
有不同利益相關者需求的項目

1. 分支模型架構

1.1 核心分支系統

main                    # 主開發分支，最新待發布版本
├── release/1.1.x       # 維護分支：1.1版本系列
├── release/1.2.x       # 維護分支：1.2版本系列  
├── release/2.0.x       # 維護分支：2.0版本系列
└── archive/1.0.x       # 歸檔分支：已停止維護版本

1.2 支持分支系統

feature/[issue-id]-description    # 功能開發分支
bugfix/[issue-id]-description     # Bug修復分支
hotfix/[version]-description       # 熱修復分支
release/prepare-[version]          # 發佈準備分支

1.3 分支命名約定

分支類型	命名格式	示例	描述
功能分支	`feature/[JIRA-123]-user-auth`	`feature/PROJ-456-oauth-login`	從main分支創建，合併回main
Bug修復	`bugfix/[JIRA-123]-fix-memory-leak`	`bugfix/PROJ-789-session-timeout`	從對應分支創建
熱修復	`hotfix/[version]-description`	`hotfix/1.2.3-security-patch`	緊急修復
發佈準備	`release/prepare-[version]`	`release/prepare-2.1.0`	預發佈準備

2. 版本號管理標準

2.1 版本編號標準

版本編號策略根據編程語言和項目類型而變化。請根據您的項目選擇合適的標準：

標準語義版本控制（SemVer）

格式：MAJOR.MINOR.PATCH[-PRE-RELEASE][+BUILD]
示例：2.1.3-alpha.1+build.20250721

版本號含義：

MAJOR（主版本號）：不兼容的API變更
MINOR（次版本號）：向後兼容的功能添加
PATCH（補丁版本號）：向後兼容的bug修復
PRE-RELEASE（預發佈版本）：預發佈版本標識符
BUILD（構建版本）：構建元數據

特定語言版本標準

Python項目（PEP 440）

格式：[N!]N(.N)*[{a|b|rc}N][.postN][.devN]
示例： 
- 1.2.0
- 1.2.0a1 (alpha版本)
- 1.2.0b1 (beta版本) 
- 1.2.0rc1 (release candidate)
- 1.2.0.post1 (post-release)
- 1.2.0.dev1 (development)

參考：Python版本説明符

Node.js/JavaScript項目

格式：MAJOR.MINOR.PATCH（嚴格SemVer）
示例：2.1.3

Java項目（Maven）

格式：MAJOR.MINOR.PATCH[-QUALIFIER]
示例：1.2.3, 1.2.3-SNAPSHOT, 1.2.3-RELEASE

Go項目

格式：vMAJOR.MINOR.PATCH（帶'v'前綴）
示例：v1.2.3

建議：選擇與您的語言生態系統和工具要求相一致的版本標準。

2.2 版本生命週期

graph LR
    A[開發版本] --> B[Alpha測試版本]
    B --> C[Beta測試版本]
    C --> D[RC候選版本]
    D --> E[正式發佈]
    E --> F[維護階段]
    F --> G[LTS長期支持]
    G --> H[EOL生命週期結束]

2.3 版本策略指導原則

版本維護策略應根據您的項目類型和組織需求進行定製。以下是推薦的方法：

應用軟件策略

針對有定期功能發佈的終端用户應用程序：

版本系列	狀態	維護類型	維護期限	支持範圍
2.0.x	當前LTS	完全維護	3年	新功能+Bug修復+安全補丁
1.2.x	維護中	有限維護	2年	Bug修復+安全補丁
1.1.x	安全維護	僅安全	1年	僅安全補丁
1.0.x	EOL	無維護	-	不支持

框架/庫軟件策略

針對框架、庫和開發者工具：

版本系列	狀態	維護類型	維護期限	支持範圍
2.0.x	當前穩定版	完全維護	直到出現重大設計缺陷	新功能+Bug修復+安全補丁
1.x.x	傳統穩定版	有限維護	直到用户遷移完成	Bug修復+安全補丁
0.x.x	實驗性	積極開發	直到穩定版發佈	允許所有變更

主要差異：

應用軟件：遵循可預測的維護週期，有計劃的EOL日期
框架軟件：只要沒有根本設計問題且用户採用率仍然顯著，就持續維護

混合策略考慮

對於兼具應用和框架特徵的項目：

API組件：遵循框架策略（更長的維護期）
UI組件：遵循應用策略（定期更新）
核心庫：遵循框架策略
客户端應用：遵循應用策略

重要説明：這些是推薦指導原則。您的實際版本策略應該考慮：

團隊能力和資源
用户羣體和遷移模式
業務需求和約束
競爭環境
技術債務管理

3. 分支保護策略

重要提示：以下分支保護規則是建議，應根據您的團隊規模、項目需求和組織結構進行調整。

3.1 分支保護規則模板

模板A：大型團隊/企業設置

# 主分支保護規則（嚴格）
main:
  protection:
    required_status_checks:
      - ci/tests
      - ci/lint
      - ci/security-scan
    required_pull_request_reviews:
      required_approving_review_count: 2
      dismiss_stale_reviews: true
      require_code_owner_reviews: true
    enforce_admins: false  # 允許倉庫擁有者繞過
    allow_force_pushes: false
    allow_deletions: false

# 維護分支保護規則  
release/*:
  protection:
    required_status_checks:
      - ci/regression-tests
      - ci/compatibility-tests
    required_pull_request_reviews:
      required_approving_review_count: 1
      require_code_owner_reviews: true
    enforce_admins: false

模板B：小團隊/初創公司設置

# 主分支保護規則（靈活）
main:
  protection:
    required_status_checks:
      - ci/tests
    required_pull_request_reviews:
      required_approving_review_count: 1
      dismiss_stale_reviews: false
      require_code_owner_reviews: false
    enforce_admins: false  # 倉庫擁有者可以直接合並
    allow_force_pushes: false
    allow_deletions: false

# 維護分支保護規則  
release/*:
  protection:
    required_status_checks:
      - ci/tests
    required_pull_request_reviews:
      required_approving_review_count: 1
      require_code_owner_reviews: false
    enforce_admins: false

模板C：開源項目

# 主分支保護規則（社區導向）
main:
  protection:
    required_status_checks:
      - ci/tests
      - ci/lint
    required_pull_request_reviews:
      required_approving_review_count: 2
      dismiss_stale_reviews: true
      require_code_owner_reviews: true
      require_review_from_code_owners: true
    enforce_admins: true  # 即使維護者也必須遵循規則
    allow_force_pushes: false
    allow_deletions: false

3.2 定製指導原則

審查要求調整：

獨立開發者：0個必需審查，依賴自動化檢查
小團隊（2-5人）：1個必需審查
中等團隊（6-15人）：2個必需審查
大團隊（16人以上）：2個以上必需審查，需要代碼擁有者要求

管理員權限：

enforce_admins: false：倉庫擁有者可以在緊急情況下繞過規則
enforce_admins: true：所有規則對所有人平等適用（推薦用於開源）

狀態檢查要求：

最小：基本測試和代碼檢查
標準：測試、代碼檢查、安全掃描
全面：測試、代碼檢查、安全、性能、兼容性檢查

3.3 合併策略

源分支 → 目標分支	合併方法	描述	何時使用
feature → main	壓縮合並	保持歷史乾淨	功能開發完成
bugfix → main	壓縮合並	簡化提交歷史	下一個版本的bug修復
bugfix → release/*	合併提交	保留完整修復歷史	特定版本的bug修復
hotfix → release/*	合併提交	易於跟蹤緊急修復	緊急生產修復
main → release/*	合併提交	創建發佈分支	初始發佈分支創建
release/* → main	櫻桃選擇	同步特定變更	僅特殊情況*

關於發佈分支流程的重要澄清：

標準流程（推薦）：

main（開發完成）→ release/X.Y.x（創建發佈分支）
hotfix → release/X.Y.x（對發佈的緊急修復）
bugfix → release/X.Y.x（發佈特定的修復）

release/* → main的特殊情況：

應該在main中的發佈特定配置變更
需要在main中反映的版本號更新
發佈過程中製作的文檔更新
發佈期間發現的構建腳本改進

⚠️ 警告：release/* → main應該是異常，而不是常規做法。main分支通常應該是真相的來源，而不是發佈分支變更的目標。

替代方法 - 發佈準備分支：

# 與其同步release -> main，不如使用準備分支：
main → release/prepare-X.Y.Z → main（準備變更）
main → release/X.Y.x（最終發佈分支）

這種方法保持main分支作為主要開發分支，同時允許發佈特定的變更得到正確集成。

4. 開發工作流程

4.1 功能開發工作流程

# 1. 創建功能分支
git checkout main
git pull origin main
git checkout -b feature/PROJ-123-new-api

# 2. 開發並提交
git add .
git commit -m "feat(api): add user authentication endpoint

- Add JWT token validation
- Implement role-based access control  
- Add API documentation

Closes: PROJ-123"

# 3. 推送並創建PR
git push origin feature/PROJ-123-new-api
# 創建Pull Request到main分支

# 4. 代碼審查和合並
# 通過PR進行代碼審查
# 自動觸發CI/CD管道
# 批准後壓縮合併到main

4.2 Bug修復工作流程

# 場景：修復1.2.x版本中的bug
# 1. 從目標維護分支創建修復分支
git checkout release/1.2.x
git pull origin release/1.2.x
git checkout -b bugfix/PROJ-456-memory-leak

# 2. 修復和測試
git add .
git commit -m "fix(memory): resolve memory leak in session handler

- Fix improper resource cleanup
- Add memory usage monitoring
- Update error handling logic

Fixes: PROJ-456"

# 3. 創建PR到維護分支
git push origin bugfix/PROJ-456-memory-leak
# PR目標：release/1.2.x

# 4. 評估是否需要櫻桃選擇到其他分支
# 如果bug影響多個版本，櫻桃選擇到相關分支

4.3 熱修復工作流程

# 緊急安全漏洞修復工作流程
# 1. 從受影響的維護分支創建熱修復分支
git checkout release/2.0.x
git pull origin release/2.0.x
git checkout -b hotfix/2.0.8-security-patch

# 2. 快速修復
git add .
git commit -m "security: fix SQL injection vulnerability

- Sanitize user input parameters
- Add input validation middleware
- Update security test cases

Security Advisory: CVE-2025-XXXX"

# 3. 緊急發佈流程
git push origin hotfix/2.0.8-security-patch
# 創建緊急PR，簡化審查流程
# 自動觸發安全測試
# 快速合併併發布

5. 發佈管理流程

5.1 常規發佈流程

# 1. 確保main分支準備好發佈
git checkout main
git pull origin main

# 驗證main分支處於可發佈狀態
# - 此版本的所有功能都已合併
# - 所有測試都通過
# - 代碼審查完成

# 2. 創建發佈準備分支（可選但推薦）
git checkout -b release/prepare-2.1.0

# 3. 發佈準備工作
# - 更新包文件中的版本號
# - 更新CHANGELOG.md
# - 更新文檔
# - 最終集成測試
# - 安全掃描

# 4. 將準備變更合併回main
git checkout main
git merge release/prepare-2.1.0
git push origin main

# 5. 從main創建發佈分支
git checkout -b release/2.1.x
git push origin release/2.1.x

# 6. 創建發佈標籤
git tag -a v2.1.0 -m "Release version 2.1.0

Features:
- User authentication system
- API rate limiting
- Performance improvements

Bug Fixes:
- Fix memory leak in session handler
- Resolve database connection timeout

Breaking Changes:
- Remove deprecated API endpoints"

git push origin v2.1.0

# 7. 清理準備分支
git branch -d release/prepare-2.1.0
git push origin --delete release/prepare-2.1.0

關鍵原則：

main始終是新版本發佈的來源
發佈分支從main創建，而不是相反
準備分支在創建最終發佈分支之前處理髮布特定的變更
熱修復直接應用到發佈分支，如果需要可以櫻桃選擇到main

5.2 發佈檢查清單模板

以下檢查清單是模板，應根據您的項目類型、團隊規模和需求進行定製。並非所有項都適用於每個項目。

模板A：Web應用程序發佈檢查清單

## 預發佈檢查清單（Web應用程序）

### 代碼質量
- [ ] 所有CI測試通過
- [ ] 代碼覆蓋率達到標準（定製：70-90%+）
- [ ] 安全掃描通過（SAST/DAST）
- [ ] 性能測試通過
- [ ] 跨瀏覽器兼容性驗證
- [ ] 可訪問性標準滿足（WCAG 2.1 AA）
- [ ] 移動響應式測試

### 文檔更新  
- [ ] API文檔更新
- [ ] 用户文檔更新
- [ ] 管理員文檔更新
- [ ] CHANGELOG.md更新
- [ ] 發佈説明準備

### 基礎設施和部署
- [ ] 數據庫遷移腳本測試
- [ ] 環境配置驗證
- [ ] CDN緩存清除計劃
- [ ] 負載均衡器配置更新
- [ ] SSL證書驗證
- [ ] 備份和回滾過程確認

### 業務和合規
- [ ] 法律/合規審查完成
- [ ] 隱私影響評估（如適用）
- [ ] 利益相關者批准獲得
- [ ] 客户溝通準備

模板B：庫/框架發佈檢查清單

## 預發佈檢查清單（庫/框架）

### 代碼質量
- [ ] 所有單元測試通過
- [ ] 集成測試通過
- [ ] 示例應用程序測試
- [ ] 性能基準穩定
- [ ] 內存泄漏測試通過
- [ ] 線程安全驗證（如適用）

### 文檔更新
- [ ] API參考更新
- [ ] 遷移指南編寫（針對破壞性變更）
- [ ] 代碼示例更新
- [ ] 教程文檔審查
- [ ] 變更日誌突出破壞性變更

### 分發和兼容性
- [ ] 包元數據更新
- [ ] 版本依賴驗證
- [ ] 平台兼容性測試
- [ ] 向後兼容性驗證
- [ ] 包簽名完成
- [ ] 倉庫發佈測試

### 社區和支持
- [ ] 破壞性變更溝通
- [ ] 社區反饋納入
- [ ] 支持渠道通知
- [ ] 問題模板更新

模板C：移動應用程序發佈檢查清單

## 預發佈檢查清單（移動應用程序）

### 測試和質量
- [ ] 設備兼容性測試
- [ ] 操作系統版本兼容性驗證
- [ ] 應用商店指導原則合規
- [ ] 性能分析完成
- [ ] 電池使用優化驗證
- [ ] 網絡條件測試

### 應用商店準備
- [ ] 應用商店元數據更新
- [ ] 截圖和促銷材料
- [ ] 應用商店描述本地化
- [ ] 隱私政策更新
- [ ] 服務條款審查
- [ ] 應用商店審查提交

### 發佈後監控
- [ ] 崩潰報告配置
- [ ] 分析跟蹤驗證
- [ ] A/B測試參數設置
- [ ] 推送通知系統測試

模板D：微服務發佈檢查清單

## 預發佈檢查清單（微服務）

### 服務質量
- [ ] 單元和集成測試通過
- [ ] 契約測試完成
- [ ] 預期流量下的負載測試
- [ ] 斷路器模式測試
- [ ] 健康檢查端點驗證

### 基礎設施
- [ ] 容器鏡像構建和掃描
- [ ] Kubernetes清單驗證
- [ ] 服務網格配置更新
- [ ] 監控和告警配置
- [ ] 日誌聚合配置
- [ ] 分佈式跟蹤啓用

### 運維就緒
- [ ] 運維手冊文檔更新
- [ ] SLA/SLO指標定義
- [ ] 事件響應過程
- [ ] 容量規劃驗證
- [ ] 回滾過程測試

定製指導原則：

小項目：專注於核心項目（測試、基本文檔、部署）
企業項目：包括所有合規、安全和流程項目
開源項目：強調社區溝通和遷移指南
MVP/原型：可能跳過一些文檔和廣泛測試需求
關鍵系統：添加額外的安全、性能和可靠性檢查

重要提示：這個檢查清單作為起點。團隊應該：

移除不適用於其環境的項目
添加項目特定需求
根據風險容忍度調整質量閾值
基於經驗教訓定期審查和更新檢查清單

6. 跨版本維護策略

6.1 安全補丁傳播

重要説明：以下表示推薦的流程指導而非自動化腳本。跨分支的櫻桃選擇通常需要手動衝突解決和仔細驗證。為了安全和準確性，團隊應該手動執行這些步驟。

安全補丁回傳流程

# 流程指導 - 為了安全，手動執行步驟

# 步驟1：在main分支中修復安全漏洞
git checkout main
# ... 通過正常開發流程執行安全修復 ...
git commit -m "security: fix authentication bypass"

# 步驟2：識別受影響的維護分支
# 需要手動評估 - 考慮：
# - 哪些版本包含有漏洞的代碼
# - 哪些版本仍在維護中
# - 客户影響和部署時間線
AFFECTED_BRANCHES="release/2.0.x release/1.2.x"

# 步驟3：每個分支的手動回傳過程
# 不要將此循環腳本化 - 單獨處理每個分支

echo "Processing security fix for release/2.0.x"
git checkout release/2.0.x
git pull origin release/2.0.x

# 嘗試櫻桃選擇
git cherry-pick -x <security-fix-commit-hash>

# 如果發生衝突（常見情況）：
# 1. 仔細解決衝突，考慮版本差異
# 2. 確保修復邏輯保持完整
# 3. 徹底測試解決的變更
# 4. 繼續櫻桃選擇過程

if [ $? -ne 0 ]; then
    echo "⚠️  需要手動衝突解決"
    echo "1. 仔細審查衝突"
    echo "2. 確保修復邏輯得以保留"
    echo "3. 徹底測試變更"
    echo "4. 準備好時運行：git cherry-pick --continue"
    exit 1
fi

# 步驟4：驗證回傳的修復
# - 運行安全特定測試
# - 在舊版本環境中驗證功能
# - 檢查迴歸問題

# 步驟5：僅在徹底驗證後推送
git push origin release/2.0.x

# 步驟6：創建安全補丁版本
# 遵循補丁版本的標準發佈流程

為什麼推薦手動流程

衝突複雜性：不同版本可能有：

不同的代碼結構或文件組織
重命名的函數或變量
修改的依賴或導入
不同的錯誤處理模式
影響修復的架構變更

風險管理：自動櫻桃選擇可能：

由於上下文差異引入細微bug
通過不當衝突解決創建安全漏洞
跳過必要的測試和驗證步驟
忽略版本特定考慮

質量保證：手動過程確保：

在每個版本環境中正確理解安全修復
為每個目標版本進行適當測試
仔細考慮版本特定約束
記錄每個版本所需的任何適應

團隊推薦工作流程

分診會議：評估哪些版本需要安全修復
首席開發者分配：為回傳分配有經驗的開發者
逐分支執行：單獨處理每個版本
獨立測試：單獨測試每個版本的修復
協調發布：計劃跨所有受影響版本同時發佈安全補丁
溝通計劃：通知用户跨所有受影響版本的安全更新

6.2 Bug修復評估矩陣

Bug嚴重性	main	當前LTS	維護版本	安全維護	EOL版本
嚴重	✅ 總是	✅ 總是	✅ 總是	✅ 總是	⚠️ 異常*
高	✅ 總是	✅ 總是	✅ 總是	❌ 通常不	❌ 無義務
中	✅ 總是	✅ 總是	⚖️ 根據需要	❌ 不	❌ 無義務
低	✅ 總是	⚖️ 根據需要	❌ 通常不	❌ 不	❌ 無義務

EOL版本考慮（⚠️ 異常情況）：

雖然開發者對EOL（生命週期結束）版本問題的修復沒有正式義務，但在異常情況下仍可能提供修復：

何時可能考慮EOL修復：

顯著市場份額：仍在EOL版本上的大用户羣（如Windows XP安全補丁）
嚴重安全漏洞：可能造成廣泛傷害的漏洞利用
聲譽管理：可能損害項目可信度的高調漏洞
法律/合規要求：某些行業的監管義務
企業關係：與有特殊支持協議的主要企業客户
社區壓力：對特定修復的強烈社區倡導

EOL修復決策框架：

當以下所有條件都適用時考慮EOL修復：
- [ ] 嚴重或安全嚴重性級別
- [ ] 顯著用户影響（可量化）
- [ ] 所需開發工作合理
- [ ] 無可行的變通方法
- [ ] 明確的業務或社區理由

附加因素：
- [ ] 修復不引入新的維護負擔
- [ ] 明確溝通這是異常情況
- [ ] 強烈建議升級到受支持版本

行業示例：

Microsoft Windows XP：由於廣泛部署，EOL後繼續安全補丁數年
Oracle Java：商業支持下的舊版本安全更新
Ubuntu LTS：舊版本的擴展安全維護
Red Hat Enterprise Linux：擴展生命週期支持程序

重要免責聲明：

無義務：EOL版本不獲得保證支持
盡力而為：任何修復都是"按現狀"提供，無保證
有限範圍：僅嚴重/安全問題，絕不添加功能
升級鼓勵：始終建議遷移到受支持版本
資源依賴：受團隊能力和優先級限制

溝通策略：

當提供EOL修復時，明確溝通：

這是異常情況，不是恢復支持
版本仍然是EOL，沒有未來修復的保證
強烈建議升級到受支持版本
將要解決的範圍有限

記住：目標是在社區責任與可持續開發實踐之間取得平衡。EOL版本修復應該是異常，而不是規則。

6.3 櫻桃選擇最佳實踐

櫻桃選擇是一個強大但潛在有風險的操作，需要仔細關注上下文和徹底測試。遵循這些實踐以確保安全和成功的櫻桃選擇。

逐步櫻桃選擇過程

1. 櫻桃選擇前評估

# 開始前，評估提交的櫻桃選擇適宜性
git show <commit-hash>

評估檢查清單：

[ ] 提交是自包含的（不依賴其他提交）
[ ] 提交不包括大型重構變更
[ ] 目標分支在受影響區域有相似的代碼結構
[ ] 目標分支沒有最近的架構變更
[ ] 提交不修改目標分支中不存在的文件

2. 準備目標分支

# 確保目標分支是最新且乾淨的
git checkout target-branch
git pull origin target-branch
git status  # 驗證乾淨的工作目錄

3. 執行櫻桃選擇並保留元數據

# 使用-x參數記錄原始提交參考
git cherry-pick -x <commit-hash>

# 對於需要署名保留的提交
git cherry-pick -x --signoff <commit-hash>

4. 處理成功場景

# 如果櫻桃選擇成功且無衝突
git log -1  # 驗證提交應用正確
# 運行相關測試以確保功能
# 僅在驗證後推送
git push origin target-branch

5. 處理衝突場景

簡單衝突（文本重疊）：

# 當衝突發生時
git status  # 顯示衝突文件

# 對於每個衝突文件：
# 1. 在編輯器中打開文件
# 2. 查找衝突標記：<<<<<<<, =======, >>>>>>>
# 3. 手動解決，保留原始修復的意圖
# 4. 刪除衝突標記
# 5. 暫存解決的文件

git add resolved-file.js
git cherry-pick --continue

複雜衝突（結構差異）：

# 對於主要結構衝突，考慮替代方法：

# 選項1：中止並創建手動補丁
git cherry-pick --abort
# 為目標分支上下文手動創建等效修復

# 選項2：跳過並記錄原因
git cherry-pick --skip
# 在提交或問題中記錄為何此櫻桃選擇不適用

異常處理原則

何時櫻桃選擇不適當：

大型重構提交：首先分解為更小、重點突出的提交
架構變更：可能需要在目標分支中不同實現
依賴更新：可能在舊版本中引起兼容性問題
新功能添加：通常不適合維護分支
文件移動/重命名：經常引起復雜衝突

替代策略：

手動重實現：

# 當櫻桃選擇過於複雜時，為這個版本的上下文手動重新創建修復
git checkout target-branch
# 為此版本的上下文手動實現等效修復
git add modified-files
git commit -m "fix: apply equivalent fix for [original-issue]

Equivalent to commit <original-commit-hash> in main branch.
Adapted for version differences in target branch.

References: #issue-number"

部分櫻桃選擇：

# 從提交中僅櫻桃選擇特定文件
git checkout <commit-hash> -- specific-file.js
git add specific-file.js
git commit -m "fix: partial backport of <commit-hash>

Only applied changes from specific-file.js due to
version differences in other affected files.

Original commit: <commit-hash>"

櫻桃選擇後驗證

測試要求：

單元測試：為修改的組件運行測試
集成測試：在目標版本上下文中驗證功能
迴歸測試：確保沒有引入新問題
手動測試：測試被修復的特定場景

文檔要求：

# 記錄櫻桃選擇關係
git log --oneline --grep="cherry picked from commit"

# 用於跟蹤和將來參考
echo "Cherry-pick completed: $(git rev-parse HEAD)" >> cherry-pick-log.md
echo "Original commit: <original-hash>" >> cherry-pick-log.md
echo "Target branch: $(git branch --show-current)" >> cherry-pick-log.md
echo "Date: $(date)" >> cherry-pick-log.md

批量櫻桃選擇指導原則

對於多個相關提交：

# 櫻桃選擇範圍（極度謹慎使用）
git cherry-pick -x <start-hash>..<end-hash>

# 如果範圍中的任何提交衝突，整個操作停止
# 逐一解決衝突，然後繼續：
git cherry-pick --continue

多個提交的更安全方法：

# 單獨處理每個提交以獲得更好控制
for commit in commit1 commit2 commit3; do
    echo "Processing $commit"
    git cherry-pick -x $commit
    
    if [ $? -ne 0 ]; then
        echo "Conflict in $commit - resolve manually"
        echo "After resolution, run: git cherry-pick --continue"
        echo "Then restart script from next commit"
        break
    fi
    
    # 在繼續前驗證每個櫻桃選擇
    echo "Cherry-pick successful, running tests..."
    # 在此處添加測試命令
done

要避免的常見陷阱

盲目解決衝突：始終理解原始修復試圖實現什麼
跳過測試：每個櫻桃選擇應在其新環境中驗證
過早櫻桃選擇：等待原始修復在其原始環境中得到證明
忽略依賴：考慮櫻桃選擇的提交是否依賴其他變更
批量操作：避免沒有人類監督的腳本批量櫻桃選擇

緊急櫻桃選擇協議

對於需要快速部署的關鍵安全修復：

# 1. 建立緊急修復專用分支
git checkout -b emergency-fix-$(date +%Y%m%d) target-branch

# 2. 櫻桃選擇時特別關注測試
git cherry-pick -x <critical-fix-hash>

# 3. 立即驗證
# 運行安全特定測試
# 驗證漏洞確實被修復
# 檢查任何迴歸問題

# 4. 快速通道審查過程
# 創建帶"SECURITY"標籤的PR
# 請求安全團隊加急審查
# 記錄緊急性和執行的驗證

# 5. 監控部署
# 監控任何意外行為
# 準備回滾計劃
# 溝通相關利益相關者

這種櫻桃選擇的全面方法確保雖然操作強大，但以必要的謹慎和驗證執行，以維護代碼質量和系統穩定性。

7. 自動化工具配置

自動化對於在版本管理實踐中維護一致性和減少人為錯誤至關重要。然而，自動化的水平和類型應該與您的項目需求、團隊規模和風險容忍度相匹配。

7.1 CI/CD流水線配置

為什麼為分支管理自動化CI/CD？

主要好處：

一致性：確保每個分支遵循相同的質量標準
早期檢測：在問題到達生產之前捕獲問題
信心：通過可靠驗證實現更快發佈
文檔：創建所有變更及其驗證的審計蹤跡

風險緩解：

防止破損代碼到達主分支
確保安全掃描在每次變更時運行
在團隊成員之間維護代碼質量標準
驗證跨不同環境的兼容性

帶理由的配置模板

# .github/workflows/ci.yml
# 目的：為所有分支類型提供全面驗證
name: CI/CD Pipeline

on:
  push:
    branches: [main, 'release/*']  # 驗證生產分支
  pull_request:
    branches: [main, 'release/*']  # 合併前驗證變更

jobs:
  # 作業1：基本驗證（快速反饋）
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16, 18, 20]  # 測試多版本兼容性
      fail-fast: false  # 如果一個失敗，繼續測試其他版本
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'  # 通過緩存加速構建
      
      - name: Install dependencies
        run: npm ci  # 使用ci獲得可重現構建
      
      - name: Run linting
        run: npm run lint
        # 目的：早期捕獲樣式問題，維護代碼一致性
      
      - name: Run unit tests
        run: npm run test:coverage
        # 目的：確保代碼功能並維護質量標準
      
      - name: Security audit
        run: npm audit --audit-level moderate
        # 目的：檢測依賴中的已知漏洞
      
      - name: Upload coverage
        uses: codecov/codecov-action@v3
        if: matrix.node-version == '18'  # 上傳一次覆蓋率避免重複
        # 目的：隨時間跟蹤測試覆蓋趨勢

  # 作業2：高級驗證（全面但較慢）
  advanced-tests:
    needs: test  # 僅在基本測試通過時運行
    runs-on: ubuntu-latest
    if: github.event_name == 'push'  # 僅在實際提交時，不是PR
    steps:
      - uses: actions/checkout@v3
      
      - name: Integration tests
        run: npm run test:integration
        # 目的：驗證組件交互
      
      - name: Performance benchmarks
        run: npm run benchmark
        # 目的：檢測性能迴歸
      
      - name: Security scanning (SAST)
        uses: securecodewarrior/github-action-add-sarif@v1
        # 目的：安全漏洞靜態分析

  # 作業3：發佈自動化（僅用於標籤）
  release:
    if: startsWith(github.ref, 'refs/tags/v')  # 僅在版本標籤時觸發
    needs: [test, advanced-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0  # 變更日誌生成需要
      
      - name: Generate Release Notes
        run: ./scripts/generate-release-notes.sh ${{ github.ref_name }}
        # 目的：自動化變更的文檔記錄
      
      - name: Create GitHub Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}
          body_path: ./release-notes.md
          draft: false
          prerelease: ${{ contains(github.ref_name, '-') }}
        # 目的：自動化發佈創建和分發

項目特定適應

對於小項目/初創公司：

# 專注於基本要素的簡化版本
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup and Test
        run: |
          npm ci
          npm run test
          npm run lint

對於企業/高安全項目：

# 增強的安全和合規
jobs:
  security-scan:
    steps:
      - name: SAST Scanning
        uses: securecodewarrior/github-action-add-sarif@v1
      - name: Container Scanning
        uses: aquasec/trivy-action@master
      - name: Dependency Check
        uses: dependency-check/Dependency-Check_Action@main
      - name: License Compliance
        run: npm run license-check

對於開源項目：

# 專注於廣泛兼容性和社區貢獻
strategy:
  matrix:
    os: [ubuntu-latest, windows-latest, macos-latest]
    node-version: [14, 16, 18, 20]
    include:
      - os: ubuntu-latest
        node-version: 21  # 測試前沿版本

對於移動應用程序：

# 平台特定測試
jobs:
  ios-build:
    runs-on: macos-latest
    steps:
      - name: Build iOS
        run: flutter build ios --no-codesign
      
  android-build:
    runs-on: ubuntu-latest
    steps:
      - name: Build Android
        run: flutter build apk --debug

7.2 版本自動化腳本

為什麼自動化版本管理？

一致性好處：

消除版本號計算中的人為錯誤
確保所有版本相關文件同時更新
維護一致的標記和分支實踐
提供版本變更的審計蹤跡

時間節省：

將發佈準備時間從小時減少到分鐘
自動化重複任務如變更日誌更新
消除記住複雜發佈過程的需要
允許專注於質量和測試而不是過程

帶決策邏輯的實現

#!/bin/bash
# scripts/release.sh - 智能發佈自動化
# 目的：在維護安全性和靈活性的同時自動化版本提升

set -e  # 出錯時退出以確保安全

# 配置 - 適應您的項目需求
VERSION_TYPE=${1:-patch}  # 默認為補丁發佈以確保安全
CURRENT_BRANCH=$(git branch --show-current)
DRY_RUN=${2:-false}  # 允許幹運行測試

echo "🚀 Starting release process..."
echo "Version type: $VERSION_TYPE"
echo "Current branch: $CURRENT_BRANCH"
echo "Dry run: $DRY_RUN"

# 安全檢查 - 防止意外發布
validate_release_conditions() {
    echo "🔍 Validating release conditions..."
    
    # 新發布必須在main分支上
    if [[ "$CURRENT_BRANCH" != "main" ]]; then
        echo "❌ Must be on main branch for releases"
        echo "Current branch: $CURRENT_BRANCH"
        exit 1
    fi

    # 工作目錄必須乾淨
    if [[ -n $(git status --porcelain) ]]; then
        echo "❌ Working directory is not clean"
        echo "Commit or stash changes before releasing"
        git status
        exit 1
    fi

    # 必須與遠程同步
    git fetch origin main
    if [[ $(git rev-list HEAD...origin/main --count) != "0" ]]; then
        echo "❌ Branch is not up to date with origin/main"
        echo "Run: git pull origin main"
        exit 1
    fi

    # 所有測試必須通過
    if ! npm test; then
        echo "❌ Tests are failing"
        exit 1
    fi
    
    echo "✅ All release conditions met"
}

# 帶驗證的版本號更新
update_version_number() {
    echo "📝 Updating version number..."
    
    if [[ "$DRY_RUN" == "true" ]]; then
        echo "DRY RUN: Would run: npm version $VERSION_TYPE --no-git-tag-version"
        NEW_VERSION=$(npm version $VERSION_TYPE --no-git-tag-version --dry-run 2>/dev/null | tail -1)
    else
        npm version $VERSION_TYPE --no-git-tag-version
        NEW_VERSION=$(node -p "require('./package.json').version")
    fi
    
    echo "📝 Updated version to $NEW_VERSION"
}

# 自動生成變更日誌
update_changelog() {
    echo "📚 Updating changelog..."
    
    if command -v ./scripts/update-changelog.sh >/dev/null 2>&1; then
        if [[ "$DRY_RUN" == "true" ]]; then
            echo "DRY RUN: Would update changelog"
        else
            ./scripts/update-changelog.sh "$NEW_VERSION"
        fi
    else
        echo "⚠️  No changelog script found, manual update may be needed"
    fi
}

# 提交版本變更
commit_version_changes() {
    echo "💾 Committing version changes..."
    
    if [[ "$DRY_RUN" == "true" ]]; then
        echo "DRY RUN: Would commit version changes"
        return
    fi
    
    git add .
    git commit -m "chore(release): bump version to $NEW_VERSION"
}

# 為minor/major版本創建發佈分支
create_release_branch() {
    if [[ "$VERSION_TYPE" == "major" || "$VERSION_TYPE" == "minor" ]]; then
        RELEASE_BRANCH="release/$(echo $NEW_VERSION | cut -d. -f1-2).x"
        echo "🌿 Creating release branch: $RELEASE_BRANCH"
        
        if [[ "$DRY_RUN" == "true" ]]; then
            echo "DRY RUN: Would create branch $RELEASE_BRANCH"
            return
        fi
        
        git checkout -b "$RELEASE_BRANCH"
        git push origin "$RELEASE_BRANCH"
        
        # 設置分支保護（如果腳本存在）
        if command -v ./scripts/setup-branch-protection.sh >/dev/null 2>&1; then
            ./scripts/setup-branch-protection.sh "$RELEASE_BRANCH"
        fi
        
        git checkout main  # 返回main
        echo "✅ Created release branch: $RELEASE_BRANCH"
    fi
}

# 創建並推送標籤
create_release_tag() {
    echo "🏷️  Creating release tag..."
    
    if [[ "$DRY_RUN" == "true" ]]; then
        echo "DRY RUN: Would create tag v$NEW_VERSION"
        return
    fi
    
    git tag -a "v$NEW_VERSION" -m "Release version $NEW_VERSION"
    git push origin main --tags
}

# 主執行流程
main() {
    validate_release_conditions
    update_version_number
    update_changelog
    commit_version_changes
    create_release_branch
    create_release_tag
    
    echo "🎉 Release $NEW_VERSION completed successfully!"
    
    if [[ "$VERSION_TYPE" == "major" || "$VERSION_TYPE" == "minor" ]]; then
        echo "📋 Next steps:"
        echo "  1. Review the new release branch: release/$(echo $NEW_VERSION | cut -d. -f1-2).x"
        echo "  2. Configure CI/CD for the new branch"
        echo "  3. Update documentation with version support matrix"
        echo "  4. Announce the new version to stakeholders"
    fi
}

# 允許幹運行測試
if [[ "$DRY_RUN" == "true" ]]; then
    echo "🧪 DRY RUN MODE - No actual changes will be made"
fi

main

項目特定定製

對於JavaScript/Node.js項目：

# 使用npm/yarn特定命令
npm version $VERSION_TYPE --no-git-tag-version
npm run build  # 確保構建產物更新
npm publish  # 如果發佈到npm registry

對於Python項目：

# 使用Python特定版本控制
pip install bump2version
bump2version $VERSION_TYPE
python setup.py sdist bdist_wheel  # 創建分發包
twine upload dist/*  # 上傳到PyPI

對於基於Docker的項目：

# 構建和標記容器鏡像
docker build -t myproject:$NEW_VERSION .
docker tag myproject:$NEW_VERSION myproject:latest
docker push myproject:$NEW_VERSION
docker push myproject:latest

對於移動應用程序：

# 更新平台特定文件中的版本
# iOS: 更新Info.plist CFBundleVersion
# Android: 更新build.gradle versionCode和versionName
./scripts/update-mobile-versions.sh $NEW_VERSION

7.3 分支保護自動化

為什麼自動化分支保護？

一致性保證：

新分支自動繼承適當的保護規則
消除配置分支策略中的人為錯誤
確保安全和質量標準始終被應用
在所有倉庫分支上提供統一體驗

運營效率：

減少新發布的手動設置時間
確保關鍵分支的即時保護
擴展以處理多個同步發佈分支
與現有GitHub/GitLab工作流集成

實現策略

#!/bin/bash
# scripts/setup-branch-protection.sh
# 目的：根據分支類型自動配置分支保護
# 用法：./setup-branch-protection.sh <branch-name>

BRANCH_NAME=${1}
REPO_OWNER=${GITHUB_REPOSITORY_OWNER:-"your-org"}
REPO_NAME=${GITHUB_REPOSITORY_NAME:-"your-repo"}
GITHUB_TOKEN=${GITHUB_TOKEN}

if [[ -z "$GITHUB_TOKEN" ]]; then
    echo "❌ GITHUB_TOKEN environment variable is required"
    echo "Create a token at: https://github.com/settings/tokens"
    exit 1
fi

if [[ -z "$BRANCH_NAME" ]]; then
    echo "❌ Branch name is required"
    echo "Usage: $0 <branch-name>"
    exit 1
fi

echo "🛡️  Setting up protection for: $BRANCH_NAME"

# 根據分支類型確定保護規則
configure_protection_rules() {
    case "$BRANCH_NAME" in
        "main")
            echo "Configuring main branch protection (strictest)"
            PROTECTION_CONFIG='{
                "required_status_checks": {
                    "strict": true,
                    "contexts": ["ci/tests", "ci/lint", "ci/security-scan", "ci/integration-tests"]
                },
                "enforce_admins": false,
                "required_pull_request_reviews": {
                    "required_approving_review_count": 2,
                    "dismiss_stale_reviews": true,
                    "require_code_owner_reviews": true,
                    "require_last_push_approval": true
                },
                "restrictions": null,
                "allow_force_pushes": false,
                "allow_deletions": false
            }'
            ;;
        release/*)
            echo "Configuring release branch protection (moderate)"
            PROTECTION_CONFIG='{
                "required_status_checks": {
                    "strict": true,
                    "contexts": ["ci/tests", "ci/regression-tests", "ci/security-scan"]
                },
                "enforce_admins": false,
                "required_pull_request_reviews": {
                    "required_approving_review_count": 1,
                    "dismiss_stale_reviews": true,
                    "require_code_owner_reviews": true
                },
                "restrictions": {
                    "users": [],
                    "teams": ["maintainers", "release-managers"],
                    "apps": []
                },
                "allow_force_pushes": false,
                "allow_deletions": false
            }'
            ;;
        archive/*)
            echo "Configuring archive branch protection (read-only)"
            PROTECTION_CONFIG='{
                "required_status_checks": null,
                "enforce_admins": true,
                "required_pull_request_reviews": null,
                "restrictions": {
                    "users": [],
                    "teams": [],
                    "apps": []
                },
                "allow_force_pushes": false,
                "allow_deletions": false
            }'
            ;;
        develop|development)
            echo "Configuring development branch protection (flexible)"
            PROTECTION_CONFIG='{
                "required_status_checks": {
                    "strict": false,
                    "contexts": ["ci/tests"]
                },
                "enforce_admins": false,
                "required_pull_request_reviews": {
                    "required_approving_review_count": 1,
                    "dismiss_stale_reviews": false,
                    "require_code_owner_reviews": false
                },
                "restrictions": null,
                "allow_force_pushes": false,
                "allow_deletions": false
            }'
            ;;
        *)
            echo "⚠️  Unknown branch type, using default protection"
            PROTECTION_CONFIG='{
                "required_status_checks": {
                    "strict": true,
                    "contexts": ["ci/tests"]
                },
                "enforce_admins": false,
                "required_pull_request_reviews": {
                    "required_approving_review_count": 1
                },
                "allow_force_pushes": false,
                "allow_deletions": false
            }'
            ;;
    esac
}

# 通過GitHub API應用保護規則
apply_protection() {
    echo "🔧 Applying protection rules..."
    
    # 進行API調用以設置分支保護
    response=$(curl -s -w "\n%{http_code}" -X PUT \
        -H "Authorization: token $GITHUB_TOKEN" \
        -H "Accept: application/vnd.github.v3+json" \
        -H "Content-Type: application/json" \
        "https://api.github.com/repos/$REPO_OWNER/$REPO_NAME/branches/$BRANCH_NAME/protection" \
        -d "$PROTECTION_CONFIG")
    
    # 提取HTTP狀態碼
    http_code=$(echo "$response" | tail -n1)
    response_body=$(echo "$response" | sed '$d')
    
    if [[ $http_code -eq 200 ]]; then
        echo "✅ Branch protection applied successfully"
        
        # 記錄配置以供審計
        echo "$(date): Protected $BRANCH_NAME in $REPO_OWNER/$REPO_NAME" >> branch-protection.log
        
        # 可選擇通知團隊
        if [[ -n "$SLACK_WEBHOOK_URL" ]]; then
            curl -X POST -H 'Content-type: application/json' \
                --data "{\"text\":\"🛡️ Branch protection configured for \`$BRANCH_NAME\` in $REPO_OWNER/$REPO_NAME\"}" \
                "$SLACK_WEBHOOK_URL"
        fi
    else
        echo "❌ Failed to apply branch protection"
        echo "HTTP Status: $http_code"
        echo "Response: $response_body"
        
        # 常見故障排除提示
        case $http_code in
            401)
                echo "💡 Hint: Check if GITHUB_TOKEN has sufficient permissions"
                ;;
            403)
                echo "💡 Hint: Token may not have admin access to the repository"
                ;;
            404)
                echo "💡 Hint: Branch may not exist or repository path is incorrect"
                ;;
        esac
        
        exit 1
    fi
}

# 主執行
configure_protection_rules
apply_protection

echo "🎉 Branch protection setup complete for $BRANCH_NAME"

項目類型考慮

對於開源項目：

# 對外部貢獻更嚴格
"enforce_admins": true  # 即使維護者也遵循規則
"required_approving_review_count": 2  # 多個審查者
"require_code_owner_reviews": true  # 領域專家必須審查

對於內部/企業項目：

# 對受信任團隊更靈活  
"enforce_admins": false  # 允許緊急情況下的管理員覆蓋
"required_approving_review_count": 1  # 單個審查者足夠
"dismiss_stale_reviews": false  # 允許較舊的批准

對於高安全項目：

# 最大保護
"required_status_checks": {
    "contexts": [
        "ci/tests", "ci/security-scan", "ci/compliance-check",
        "ci/vulnerability-scan", "ci/license-check", "ci/secret-scan"
    ]
}

對於快速開發項目：

# 最小但基本保護
"required_status_checks": {
    "strict": false,  # 允許一些靈活性
    "contexts": ["ci/tests"]  # 只確保測試通過
}

自動化工具應被視為您團隊現有流程的力量倍增器，而不是人類判斷和監督的替代品。從基本自動化開始，隨着您的團隊對工具變得舒適，逐漸增加複雜性。

8. 團隊協作標準

注意：以下協作標準應根據您的團隊規模、文化和項目需求進行調整。這些是經過驗證的實踐，可以根據需要放大或縮小規模。

8.1 代碼提交標準

格式：<type>(<scope>): <subject>

<body>

<footer>

提交類型描述：

feat：新功能
fix：bug修復
docs：文檔更新
style：代碼格式調整
refactor：代碼重構
perf：性能優化
test：測試相關
chore：構建配置等

提交示例：

feat(auth): add OAuth2 authentication support

- Implement OAuth2 authorization flow
- Add Google and GitHub providers
- Update API documentation
- Add integration tests

Closes: PROJ-123
Breaking Change: Remove basic auth support

8.2 PR審查標準模板

以下PR審查標準應根據您的項目類型、團隊經驗和組織需求進行調整。選擇並定製最適合您需求的模板。

模板A：企業/大型團隊PR模板

## Pull Request模板（企業）

### 🔄 變更類型
- [ ] 🐛 Bug修復
- [ ] ✨ 新功能
- [ ] ♻️  重構
- [ ] 📝 文檔更新
- [ ] 🚨 破壞性變更
- [ ] 🔒 安全修復

### 📋 變更描述
**摘要**：此PR完成什麼的簡要描述
**動機**：為什麼需要這個變更
**方法**：解決方案的高層描述

### 🧪 測試策略
- [ ] 單元測試已添加/更新
- [ ] 集成測試通過  
- [ ] 手動測試完成
- [ ] 性能測試完成（如適用）
- [ ] 安全測試完成（如適用）
- [ ] 可訪問性測試完成（如適用）

### 🔗 相關問題
Closes #
Relates to #
Depends on #

### 📸 截圖/視頻
<!-- 對於UI變更，包括前後截圖 -->

### ⚡ 性能影響
- [ ] 無性能影響
- [ ] 性能改進（如可能請量化）
- [ ] 性能下降（解釋必要性和緩解）

### 🔒 安全影響評估
- [ ] 無安全影響
- [ ] 安全審查完成
- [ ] 滲透測試完成（如適用）
- [ ] 隱私影響評估

### 📚 文檔更新
- [ ] 不需要文檔
- [ ] API文檔更新
- [ ] 用户指南更新
- [ ] 架構文檔更新
- [ ] 部署指南更新

### 🌍 國際化
- [ ] 無i18n影響
- [ ] 新字符串添加到翻譯文件
- [ ] 文化敏感性審查

### ♿ 可訪問性
- [ ] 無可訪問性影響
- [ ] WCAG指導原則遵循
- [ ] 屏幕閲讀器測試完成

### ✅ 審查檢查清單
#### 代碼質量
- [ ] 代碼遵循既定模式和標準
- [ ] 錯誤處理全面
- [ ] 資源清理得當
- [ ] 線程安全考慮（如適用）

#### 架構和設計
- [ ] 解決方案遵循SOLID原則
- [ ] 依賴最小化且合理
- [ ] API設計一致
- [ ] 數據庫變更向後兼容

#### 安全
- [ ] 輸入驗證實現
- [ ] 授權控制驗證
- [ ] 敏感數據處理安全
- [ ] 第三方依賴審計

---
/assign @senior-dev-team @security-team @architecture-team

模板B：初創公司/小團隊PR模板

## Pull Request模板（小團隊）

### 這個PR做什麼？
變更的簡要描述

### 為什麼需要這個？
變更的背景和動機

### 如何測試的？
- [ ] 測試在本地通過
- [ ] 手動測試完成
- [ ] 邊緣案例考慮

### 相關問題
Fixes #

### 截圖（如適用）
<!-- 包括UI變更的截圖 -->

### 檢查清單
- [ ] 代碼乾淨且可讀
- [ ] 沒有明顯bug或安全問題
- [ ] 如需要文檔已更新
- [ ] 準備好審查

---
/assign @team

模板C：開源項目PR模板

## Pull Request模板（開源）

### 描述
這個變更做什麼？為什麼必要？

### 變更類型
- [ ] Bug修復（修復問題的非破壞性變更）
- [ ] 新功能（添加功能的非破壞性變更）
- [ ] 破壞性變更（會導致現有功能不按預期工作的修復或功能）
- [ ] 文檔更新

### 測試
描述您運行的測試以及如何重現：
- [ ] 測試A
- [ ] 測試B

### 截圖（如適用）

### 檢查清單
- [ ] 我的代碼遵循項目的樣式指導原則
- [ ] 我已執行代碼自我審查
- [ ] 我已註釋代碼，特別是難以理解的區域
- [ ] 我已對文檔做出相應變更
- [ ] 我的變更不產生新警告
- [ ] 我已添加證明修復有效或功能工作的測試
- [ ] 新的和現有的單元測試在我的變更下本地通過

### 附加説明
審查者應該知道的任何附加信息

模板D：庫/框架PR模板

## Pull Request模板（庫/框架）

### 變更摘要
此PR變更的簡要描述

### 破壞性變更
- [ ] 無
- [ ] 輕微（影響邊緣案例）
- [ ] 重大（影響常見使用模式）

**如果存在破壞性變更，描述遷移路徑：**

### API變更
- [ ] 無API變更
- [ ] 新API添加
- [ ] 現有API修改
- [ ] API棄用

### 性能影響
- [ ] 無可測量影響
- [ ] 性能改進（包括基準測試）
- [ ] 性能迴歸（證明必要性）

### 測試
- [ ] 單元測試已添加/更新
- [ ] 集成測試通過
- [ ] 示例項目測試
- [ ] 向後兼容性驗證

### 文檔
- [ ] API文檔更新
- [ ] 遷移指南更新（針對破壞性變更）
- [ ] 示例更新
- [ ] 變更日誌條目添加

### 兼容性
測試的版本：
- [ ] Node.js版本： 
- [ ] 瀏覽器版本：
- [ ] 操作系統：

---
/assign @maintainers @docs-team

模板選擇指導原則：

項目類型	推薦模板	關鍵焦點領域
企業軟件	模板A	安全、合規、文檔
初創公司MVP	模板B	速度、基本質量檢查
開源庫	模板C	社區指導原則、廣泛兼容性
框架/SDK	模板D	API穩定性、性能、示例
內部工具	模板B（簡化）	團隊標準、基本質量
關鍵系統	模板A（擴展）	額外安全和保障檢查

定製原則：

對於較小團隊或更簡單項目，減少複雜性
添加特定域檢查（如醫療保健的HIPAA合規）
根據團隊經驗水平調整審查要求
包括自動化以減少手動檢查清單項目
基於審查中發現的常見問題定期模板更新

重要提示：PR模板應該為您的團隊服務，而不是成為負擔。從簡單開始，只有在提供明確價值時才增加複雜性。

8.3 角色權限矩陣（建議框架）

角色	main分支	release分支	feature分支	發佈權限
開發者	僅PR	僅PR	完全訪問	❌
高級開發者	PR + 審查	PR + 審查	完全訪問	❌
維護者	完全訪問	完全訪問	完全訪問	有限
發佈管理者	完全訪問	完全訪問	完全訪問	完全訪問

定製指導原則：

小團隊：可能合併角色（如，所有開發者也是審查者）
開源：可能添加權限有限的"貢獻者"角色
企業：可能添加額外角色如"安全審查者"或"架構審查者"
初創公司：可能給予更廣泛權限以加速開發

權限類型解釋：

僅PR：可以創建拉取請求但不能合併
PR + 審查：可以審查和批准他人的拉取請求
完全訪問：可以直接推送和合並拉取請求
有限：可以發佈補丁版本但不能發佈major/minor版本

9. 監控和指標

有效的監控提供您的版本管理流程健康狀況的可視性，並幫助識別改進領域。監控方法應該與您的項目規模和風險概況相匹配。

9.1 分支健康監控

為什麼監控分支健康？

早期問題檢測：

識別偏離main太遠的分支
檢測陳舊或被放棄的功能分支
在合併衝突變為關鍵之前發現潛在合併衝突
監控可能需要關注或清理的分支

團隊協調：

對正在進行的開發工作的可視性
對發佈分支準備狀態的理解
識別開發流程中的瓶頸
為分支生命週期管理做數據驅動決策

質量保證：

確保分支保持可接受的分歧水平
監控對分支標準的遵守
跟蹤合併策略的有效性
驗證自動化正在正常工作

帶上下文感知分析的實現

#!/bin/bash
# scripts/branch-health-monitor.sh
# 目的：帶可行洞察的綜合分支健康分析

WEBHOOK_URL="${SLACK_WEBHOOK_URL}"
REPO_NAME=$(basename -s .git `git config --get remote.origin.url`)
ALERT_THRESHOLD_COMMITS=50  # 根據您團隊的速度定製
WARNING_THRESHOLD_COMMITS=20

echo "🏥 Starting comprehensive branch health check..."

generate_health_report() {
    local report_file="branch-health-$(date +%Y%m%d-%H%M).md"
    
    echo "# Branch Health Report - $(date)" > "$report_file"
    echo "Repository: $REPO_NAME" >> "$report_file"
    echo "" >> "$report_file"
    
    # 分析1：分支同步狀態
    echo "## Branch Synchronization Analysis" >> "$report_file"
    echo "| Branch | Ahead | Behind | Status | Recommendation |" >> "$report_file"
    echo "|--------|-------|--------|---------|----------------|" >> "$report_file"
    
    for branch in $(git branch -r | grep 'origin/release/' | sed 's/origin\///'); do
        local ahead=$(git rev-list --count $branch..main 2>/dev/null || echo "0")
        local behind=$(git rev-list --count main..$branch 2>/dev/null || echo "0")
        local status
        local recommendation
        
        if [ "$behind" -gt $ALERT_THRESHOLD_COMMITS ]; then
            status="🔴 Critical"
            recommendation="Immediate attention needed - consider cherry-picking critical fixes"
        elif [ "$behind" -gt $WARNING_THRESHOLD_COMMITS ]; then
            status="🟡 Warning"
            recommendation="Monitor closely - may need selective updates"
        else
            status="🟢 Good"
            recommendation="No action needed"
        fi
        
        echo "| $branch | $ahead | $behind | $status | $recommendation |" >> "$report_file"
    done
    
    # 分析2：開發速度指標
    echo "" >> "$report_file"
    echo "## Development Velocity Metrics" >> "$report_file"
    
    local commits_last_week=$(git log --since="1 week ago" --oneline | wc -l)
    local commits_last_month=$(git log --since="1 month ago" --oneline | wc -l)
    local avg_commits_per_week=$((commits_last_month / 4))
    
    echo "- Commits this week: $commits_last_week" >> "$report_file"
    echo "- Average commits per week: $avg_commits_per_week" >> "$report_file"
    
    if [ $commits_last_week -lt $((avg_commits_per_week / 2)) ]; then
        echo "- ⚠️ Activity below average - check if team is blocked" >> "$report_file"
    fi
    
    # 分析3：PR和分支生命週期分析
    echo "" >> "$report_file"
    echo "## Pull Request Health" >> "$report_file"
    
    if command -v gh >/dev/null 2>&1; then
        local old_prs=$(gh pr list --state open --json number,title,createdAt,author --limit 50 | \
            jq -r '.[] | select((now - (.createdAt | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime)) > (7*24*3600)) | "- ⏰ #\(.number): \(.title) (by \(.author.login), \(((now - (.createdAt | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime)) / (24*3600) | floor)) days old)"')
        
        if [ -n "$old_prs" ]; then
            echo "### Stale Pull Requests (>7 days)" >> "$report_file"
            echo "$old_prs" >> "$report_file"
            echo "" >> "$report_file"
            echo "**Recommendation**: Review these PRs for potential blockers or closure" >> "$report_file"
        else
            echo "### ✅ No stale pull requests found" >> "$report_file"
        fi
    fi
    
    # 分析4：安全和合規檢查
    echo "" >> "$report_file"
    echo "## Security and Compliance Status" >> "$report_file"
    
    # 檢查具有潛在安全問題的分支
    local security_branches=$(git branch -r | grep -E "(security|hotfix)" | wc -l)
    if [ $security_branches -gt 0 ]; then
        echo "- 🔒 $security_branches active security/hotfix branches detected" >> "$report_file"
        echo "- **Action Required**: Verify these are being addressed promptly" >> "$report_file"
    fi
    
    # 分析5：基於發現的建議
    echo "" >> "$report_file"
    echo "## Recommended Actions" >> "$report_file"
    
    local critical_branches=$(git for-each-ref --format='%(refname:short)' refs/remotes/origin/release/ | \
        while read branch; do
            local behind=$(git rev-list --count main..$branch 2>/dev/null || echo "0")
            if [ "$behind" -gt $ALERT_THRESHOLD_COMMITS ]; then
                echo "$branch"
            fi
        done | wc -l)
    
    if [ $critical_branches -gt 0 ]; then
        echo "1. **Urgent**: Review $critical_branches branches that are significantly behind main" >> "$report_file"
        echo "2. Consider cherry-picking critical fixes or planning maintenance updates" >> "$report_file"
    fi
    
    if [ $commits_last_week -eq 0 ]; then
        echo "3. **Team Check**: No commits this week - verify team availability and blockers" >> "$report_file"
    fi
    
    echo "$report_file"
}

send_notifications() {
    local report_file=$1
    
    # 如果配置，發送到Slack
    if [ -n "$WEBHOOK_URL" ]; then
        local summary=$(head -20 "$report_file" | tail -15)  # 獲得關鍵發現
        
        curl -X POST -H 'Content-type: application/json' \
            --data "{
                \"text\": \"📊 $REPO_NAME Branch Health Report\",
                \"attachments\": [{
                    \"color\": \"good\",
                    \"title\": \"Latest Health Check Results\",
                    \"text\": \"\`\`\`$summary\`\`\`\",
                    \"footer\": \"Full report: $report_file\"
                }]
            }" \
            "$WEBHOOK_URL"
    fi
    
    # 可選擇發送郵件報告（如果配置）
    if [ -n "$HEALTH_REPORT_EMAIL" ]; then
        mail -s "Branch Health Report - $REPO_NAME" "$HEALTH_REPORT_EMAIL" < "$report_file"
    fi
}

# 主執行
report_file=$(generate_health_report)
send_notifications "$report_file"

echo "📋 Branch health analysis complete"
echo "Report saved: $report_file"

# 基於發現返回退出代碼（對CI集成有用）
critical_issues=$(git for-each-ref --format='%(refname:short)' refs/remotes/origin/release/ | \
    while read branch; do
        behind=$(git rev-list --count main..$branch 2>/dev/null || echo "0")
        if [ "$behind" -gt $ALERT_THRESHOLD_COMMITS ]; then
            echo "1"
        fi
    done | wc -l)

if [ $critical_issues -gt 0 ]; then
    echo "⚠️ $critical_issues branches require immediate attention"
    exit 1
else
    echo "✅ All branches are in acceptable health"
    exit 0
fi

項目特定監控適應

對於高速項目：

# 為快節奏團隊調整閾值
ALERT_THRESHOLD_COMMITS=100  # 期望更多提交
WARNING_THRESHOLD_COMMITS=50
CHECK_FREQUENCY="daily"  # 更頻繁監控

對於穩定/成熟項目：

# 為較慢、更深思熟慮的開發調整
ALERT_THRESHOLD_COMMITS=20   # 期望較少提交
WARNING_THRESHOLD_COMMITS=10
CHECK_FREQUENCY="weekly"     # 較少頻繁監控需要

對於開源項目：

# 專注於社區健康指標
echo "## Community Metrics" >> "$report_file"
echo "- Active contributors this month: $(git log --since='1 month ago' --format='%an' | sort -u | wc -l)" >> "$report_file"
echo "- First-time contributors: $(git log --since='1 month ago' --format='%an' | sort | uniq -c | awk '$1==1' | wc -l)" >> "$report_file"

9.2 發佈質量指標

為什麼跟蹤發佈質量？

持續改進：

識別發佈問題中的模式以防止未來問題
衡量質量門和流程的有效性
隨時間跟蹤改進趨勢
為流程變更做數據驅動決策

風險管理：

潛在發佈問題的早期警告信號
瞭解故障模式及其頻率
驗證質量流程正在工作
合規和審計需求的證據

團隊表現：

認可流程成熟度的改進
識別培訓或工具需求
對標行業標準
支持資源分配決策

綜合質量跟蹤

#!/bin/bash
# scripts/release-quality-monitor.sh
# 目的：跟蹤發佈質量趨勢並識別改進機會

echo "📈 Starting release quality analysis..."

calculate_release_metrics() {
    echo "## Release Frequency Analysis"
    
    # 近期發佈活動
    local releases_last_month=$(git tag --sort=-creatordate | head -20 | \
        xargs -I {} git log -1 --format="%ct" {} 2>/dev/null | \
        awk -v cutoff=$(date -d '30 days ago' +%s) '$1 > cutoff' | wc -l)
    
    local releases_last_quarter=$(git tag --sort=-creatordate | head -50 | \
        xargs -I {} git log -1 --format="%ct" {} 2>/dev/null | \
        awk -v cutoff=$(date -d '90 days ago' +%s) '$1 > cutoff' | wc -l)
    
    echo "Releases in last 30 days: $releases_last_month"
    echo "Releases in last 90 days: $releases_last_quarter"
    
    # 發佈速度趨勢
    if [ $releases_last_month -gt 0 ]; then
        local monthly_velocity=$((releases_last_quarter / 3))
        echo "Average monthly release velocity: $monthly_velocity"
        
        if [ $releases_last_month -gt $((monthly_velocity * 2)) ]; then
            echo "⚠️ Release frequency above normal - verify quality processes"
        elif [ $releases_last_month -eq 0 ] && [ $monthly_velocity -gt 0 ]; then
            echo "⚠️ No releases this month - check for blockers"
        fi
    fi
}

analyze_hotfix_patterns() {
    echo ""
    echo "## Hotfix and Emergency Release Analysis"
    
    # 統計熱修復和緊急發佈
    local hotfix_count=$(git log --since="90 days ago" --grep="hotfix\|emergency" --oneline | wc -l)
    local total_releases=$(git tag --sort=-creatordate | head -20 | \
        xargs -I {} git log -1 --format="%ct" {} 2>/dev/null | \
        awk -v cutoff=$(date -d '90 days ago' +%s) '$1 > cutoff' | wc -l)
    
    if [ $total_releases -gt 0 ]; then
        local hotfix_ratio=$((hotfix_count * 100 / total_releases))
        echo "Hotfix ratio: $hotfix_ratio% ($hotfix_count out of $total_releases releases)"
        
        if [ $hotfix_ratio -gt 20 ]; then
            echo "🔴 High hotfix ratio - review quality gates and testing processes"
            echo "Recommended actions:"
            echo "- Increase pre-release testing coverage"
            echo "- Review code review effectiveness"
            echo "- Consider additional automated quality checks"
        elif [ $hotfix_ratio -gt 10 ]; then
            echo "🟡 Moderate hotfix ratio - monitor quality processes"
        else
            echo "🟢 Low hotfix ratio - quality processes appear effective"
        fi
    fi
    
    # 近期熱修復分析
    if [ $hotfix_count -gt 0 ]; then
        echo ""
        echo "### Recent Hotfix Reasons:"
        git log --since="90 days ago" --grep="hotfix\|emergency" --format="- %s (%ar)" | head -5
    fi
}

measure_development_lead_time() {
    echo ""
    echo "## Development Lead Time Analysis"
    
    # 估計近期發佈從第一個提交到發佈的前置時間
    local recent_tags=$(git tag --sort=-creatordate | head -5)
    
    echo "### Recent Release Lead Times:"
    for tag in $recent_tags; do
        # 獲取標籤的提交日期
        local tag_date=$(git log -1 --format="%ct" "$tag" 2>/dev/null)
        
        # 獲取自上一個標籤以來的提交
        local prev_tag=$(git tag --sort=-creatordate | grep -A1 "^$tag$" | tail -1)
        
        if [ -n "$prev_tag" ] && [ "$prev_tag" != "$tag" ]; then
            local first_commit_date=$(git log --format="%ct" "$prev_tag..$tag" | tail -1)
            
            if [ -n "$first_commit_date" ] && [ -n "$tag_date" ]; then
                local lead_time_days=$(( (tag_date - first_commit_date) / 86400 ))
                echo "- $tag: $lead_time_days days from first commit to release"
            fi
        fi
    done
}

check_quality_gates() {
    echo ""
    echo "## Quality Gate Effectiveness"
    
    # 檢查近期提交的質量指標
    local total_commits=$(git log --since="30 days ago" --oneline | wc -l)
    local tested_commits=$(git log --since="30 days ago" --grep="test" --oneline | wc -l)
    local reviewed_commits=$(git log --since="30 days ago" --grep="Reviewed-by\|Co-authored-by" --oneline | wc -l)
    
    if [ $total_commits -gt 0 ]; then
        local test_coverage_ratio=$((tested_commits * 100 / total_commits))
        local review_ratio=$((reviewed_commits * 100 / total_commits))
        
        echo "Recent commit quality indicators:"
        echo "- Commits with test references: $test_coverage_ratio%"
        echo "- Commits with review indicators: $review_ratio%"
        
        if [ $test_coverage_ratio -lt 30 ]; then
            echo "⚠️ Low test-related commit ratio - consider emphasizing testing"
        fi
        
        if [ $review_ratio -lt 50 ]; then
            echo "⚠️ Low review indicator ratio - verify PR review process"
        fi
    fi
}

generate_recommendations() {
    echo ""
    echo "## Quality Improvement Recommendations"
    
    # 基於指標生成建議
    local issues_found=0
    
    # 檢查表明需要改進的質量模式
    local recent_hotfixes=$(git log --since="30 days ago" --grep="hotfix" --oneline | wc -l)
    if [ $recent_hotfixes -gt 2 ]; then
        echo "1. **Quality Gate Enhancement**: $recent_hotfixes hotfixes in 30 days suggests need for:"
        echo "   - Enhanced automated testing coverage"
        echo "   - Stricter pre-release validation"
        echo "   - Additional security scanning"
        issues_found=$((issues_found + 1))
    fi
    
    # 檢查發佈頻率問題
    local recent_releases=$(git tag --sort=-creatordate | head -10 | \
        xargs -I {} git log -1 --format="%ct" {} 2>/dev/null | \
        awk -v cutoff=$(date -d '60 days ago' +%s) '$1 > cutoff' | wc -l)
    
    if [ $recent_releases -eq 0 ]; then
        echo "2. **Release Cadence**: No releases in 60 days - consider:"
        echo "   - Review of release blockers"
        echo "   - Process simplification for smaller releases"
        echo "   - Feature flagging to enable more frequent releases"
        issues_found=$((issues_found + 1))
    elif [ $recent_releases -gt 10 ]; then
        echo "2. **Release Stability**: High release frequency ($recent_releases in 60 days) - consider:"
        echo "   - Batch smaller changes into fewer releases"
        echo "   - Enhanced staging environment testing"
        echo "   - Feature stabilization periods"
        issues_found=$((issues_found + 1))
    fi
    
    if [ $issues_found -eq 0 ]; then
        echo "✅ Release quality metrics appear healthy - maintain current processes"
    fi
}

# 根據項目類型定義質量閾值
set_quality_thresholds() {
    case "${PROJECT_TYPE:-application}" in
        "library"|"framework")
            # 庫需要更高穩定性
            ACCEPTABLE_HOTFIX_RATIO=5
            TARGET_LEAD_TIME_DAYS=14
            ;;
        "enterprise")
            # 企業軟件需要平衡速度和穩定性
            ACCEPTABLE_HOTFIX_RATIO=10
            TARGET_LEAD_TIME_DAYS=21
            ;;
        "startup"|"mvp")
            # 初創公司可能接受更高熱修復比率換取速度
            ACCEPTABLE_HOTFIX_RATIO=20
            TARGET_LEAD_TIME_DAYS=7
            ;;
        *)
            # 默認應用設置
            ACCEPTABLE_HOTFIX_RATIO=15
            TARGET_LEAD_TIME_DAYS=14
            ;;
    esac
}

# 主執行
set_quality_thresholds
calculate_release_metrics
analyze_hotfix_patterns
measure_development_lead_time
check_quality_gates
generate_recommendations

echo ""
echo "📊 Quality analysis complete - review recommendations above"

質量指標儀表板

對於想要隨時間跟蹤趨勢的團隊，考慮實施簡單的指標儀表板：

# scripts/generate-metrics-dashboard.sh
# 創建質量指標的簡單HTML儀表板

cat > metrics-dashboard.html << 'EOF'
<!DOCTYPE html>
<html>
<head>
    <title>Release Quality Dashboard</title>
    <script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
    <style>
        body { font-family: Arial, sans-serif; margin: 20px; }
        .metric-card { background: #f5f5f5; padding: 15px; margin: 10px 0; border-radius: 5px; }
        .chart-container { width: 600px; height: 400px; margin: 20px 0; }
    </style>
</head>
<body>
    <h1>Release Quality Dashboard</h1>
    
    <div class="metric-card">
        <h3>Current Month Summary</h3>
        <p>Generated: <span id="report-date"></span></p>
        <p>Releases: <span id="release-count"></span></p>
        <p>Hotfixes: <span id="hotfix-count"></span></p>
        <p>Quality Score: <span id="quality-score"></span></p>
    </div>
    
    <div class="chart-container">
        <canvas id="releaseFrequencyChart"></canvas>
    </div>
    
    <script>
        // 使用實際指標數據填充
        document.getElementById('report-date').textContent = new Date().toLocaleDateString();
        // 在此處添加您的指標數據
    </script>
</body>
</html>
EOF

echo "📊 Metrics dashboard generated: metrics-dashboard.html"

監控和指標方法應該隨着您的項目成熟度而增長。從基本分支健康監控開始，隨着您的團隊在工具和流程方面的熟練程度發展，逐漸添加更復雜的質量跟蹤。

10. 文檔和培訓

有效的文檔和培訓對於版本管理實踐的成功採用至關重要。方法應該根據您團隊的經驗水平、項目複雜性和組織文化進行定製。

10.1 團隊培訓策略

為什麼投資培訓？

減少錯誤和不一致：

防止不正確分支或合併導致的昂貴錯誤
確保團隊成員理解流程背後的原理
創建最佳實踐和例外的共同理解
在處理複雜場景時建立信心

加速入職：

新團隊成員更快變得高效
減少高級開發者回答基本Git問題的負擔
在團隊成員之間建立一致的工作流程
為高級實踐和自動化創造基礎

啓用流程演進：

具有強基礎的團隊可以隨需求變化調整流程
減少對流程改進和工具採用的阻力
創造團隊成員為流程完善貢獻的能力
建立在團隊變化中持續的組織知識

分層培訓方法

級別1：基礎培訓（所有團隊成員）

持續時間：2-3小時
先決條件：基本Git知識
格式：帶動手練習的互動工作坊

核心主題：

## 基礎培訓課程

### Git基礎回顧（30分鐘）
- 分支和合並概念
- 遠程倉庫交互
- 基本衝突解決
- 命令行vs GUI工具使用

### 分支模型理解（45分鐘）
- 我們特定的分支架構和原理
- 何時使用不同分支類型
- 分支命名約定及其重要性
- 從開發到發佈的功能生命週期

### 日常工作流程實踐（60分鐘）
**動手練習**：創建功能分支，進行變更，創建PR
- 創建和使用功能分支
- 編寫有效的提交消息
- 創建有意義的拉取請求
- 作為作者和審查者參與代碼審查

### 常見場景工作坊（30分鐘）
**互動問題解決：**
- 當您的分支與main衝突時該怎麼辦
- 如何在功能工作進行中處理緊急修復
- 何時以及如何在複雜Git情況下尋求幫助
- 理解何時cherry-pick vs merge vs rebase

評估方法：

實踐練習：完成功能開發週期
提交消息和PR描述的同行審查
解決您項目實際場景的Q&A會話

級別2：高級實踐（高級開發者、負責人）

持續時間：3-4小時
先決條件：級別1完成 + 6個月經驗
格式：帶您項目歷史案例研究的工作坊

高級主題：

## 高級培訓課程

### 複雜合併衝突解決（60分鐘）
- 理解衝突類型及其根本原因
- 複雜衝突的戰略方法
- 大規模衝突的工具和技術
- 何時尋求幫助vs獨立解決

### 跨分支維護策略（60分鐘）
- Cherry-picking最佳實踐和陷阱
- 跨版本的安全補丁傳播
- 管理跨發佈分支的破壞性變更
- 版本兼容性規劃和測試

### 發佈工程（90分鐘）
**案例研究分析**：審查您項目的2-3個實際發佈
- 發佈規劃和準備
- 協調多分支發佈
- 緊急發佈程序
- 發佈後監控和回滾規劃

### 流程改進和自動化（60分鐘）
- 識別自動化機會
- 為流程文檔貢獻
- 指導初級團隊成員
- 為變化的項目需求調整流程

級別3：維護者/發佈管理者培訓（領導角色）

持續時間：4-6小時
先決條件：級別2完成 + 展示的專業知識
格式：帶真實項目場景的工作會話

領導主題：

## 維護者培訓課程

### 分支策略設計和演進（90分鐘）
- 評估和調整項目變更的分支策略
- 平衡開發速度與穩定性需求
- 管理版本支持生命週期和EOL決策
- 向利益相關者傳達策略變更

### 緊急響應和事件管理（90分鐘）
**模擬練習**：處理關鍵安全事件
- 快速評估和分類程序
- 協調跨團隊緊急響應
- 事件期間的溝通策略
- 事件後分析和流程改進

### 團隊領導和流程倡導（60分鐘）
- 培訓和指導團隊成員
- 管理對流程變更的阻力
- 在技術決策上建立共識
- 向業務利益相關者代表技術需求

### 高級自動化和工具（90分鐘）
- 設計和實施自動化工作流程
- 將版本管理與部署管道集成
- 監控和警報策略
- 工具選擇和供應商評估

按項目類型的培訓定製

對於初創公司/小團隊：

## 簡化培訓方法

### 合併級別1+2培訓（4小時）
- 只專注於基本實踐
- 強調靈活性和快速迭代
- 包括"何時打破規則"指導
- 強烈強調溝通和協調

### 關鍵調整：
- 較少正式流程，更多指導原則
- 強調可逆決策
- 專注於速度，同時保持基本質量
- 交叉培訓，以便團隊成員可以覆蓋多個角色

對於企業/大型組織：

## 全面培訓計劃

### 多周培訓系列
- 第1周：基礎（所有開發者）
- 第2周：高級實踐（高級人員）
- 第3周：專業化軌道（web、移動、後端）
- 第4周：與企業工具集成

### 關鍵增加：
- 合規和審計需求
- 與企業系統集成（JIRA、ServiceNow等）
- 安全和訪問控制考慮
- 文檔和變更管理流程

對於開源項目：

## 面向社區的培訓

### 公共文檔重點
- 異步學習的全面書面指南
- 視覺學習者的視頻教程
- 社區Q&A論壇和辦公時間
- 貢獻者入職計劃

### 關鍵考慮：
- 多個技能水平和經驗背景
- 不同時區和可用性
- 語言和文化考慮
- 志願者vs付費貢獻者動態

10.2 文檔架構

為什麼結構化文檔重要？

自助服務知識庫：

減少常見問題的中斷
使團隊成員能夠快速找到答案
無論誰問都提供一致的信息
比人與人之間的知識傳遞擴展得更好

流程一致性：

確保每個人都遵循相同的程序
減少團隊成員之間實施的差異
為定期流程審查和更新提供參考
為自動化和工具決策創建基礎

機構知識保存：

捕獲決策背後的上下文和理由
在團隊成員流動中存續
提供理解為什麼流程存在的歷史
啓用關於未來變更的知情決策

文檔結構模板

級別1：快速入門指南

# Git工作流程快速入門

## 新團隊成員TL;DR

### 日常開發
1. `git checkout main && git pull` - 從最新開始
2. `git checkout -b feature/TICKET-123-description` - 創建分支
3. 進行變更，用好消息提交
4. `git push`並創建PR到main
5. 獲得審查，解決反饋，合併

### 緊急修復
1. 識別目標分支（通常最新的release/X.Y.x）
2. 創建hotfix/X.Y.Z-description分支
3. 修復、測試、PR到發佈分支
4. 遵循加快的審查流程

### 何時尋求幫助
- 複雜合併衝突
- 需要跨多個分支cherry-pick
- 不確定針對哪個分支
- 影響多個版本的破壞性變更

### 常用命令
[包括您最常用的10個命令及示例]

級別2：完整流程指南

# 完整版本管理指南

## 分支策略概述
[您特定策略的詳細解釋]

## 詳細工作流程
### 功能開發工作流程
[帶決策點和替代方案的逐步]

### 發佈管理工作流程
[帶檢查清單和驗證的完整發布流程]

### 維護和熱修復工作流程
[發佈後支持的全面覆蓋]

## 高級場景
### 跨版本兼容性
### 大規模重構
### 破壞性變更管理
### 安全事件響應

## 工具和自動化
### 必需工具和設置
### 可選工具和集成
### 自動化腳本使用
### 監控和報告

級別3：參考文檔

# 版本管理參考

## 決策記錄
[記錄主要決策及其原理]

## 流程演進歷史
[隨時間跟蹤流程變更]

## 故障排除指南
[常見問題及其解決方案]

## 集成文檔
[版本管理如何與其他系統集成]

## 性能和擴展考慮
[高速或大團隊的指導原則]

文檔維護策略

定期審查週期：

## 季度文檔審查

### 審查檢查清單
- [ ] 程序是否仍按文檔進行？
- [ ] 是否出現了需要文檔的新常見問題？
- [ ] 是否有應該標準化的流程變化？
- [ ] 示例和截圖是否反映當前工具/界面？
- [ ] 是否有更好的自動化或工具機會？

### 更新流程
1. **收集反饋**：調查團隊痛點和建議
2. **分析缺口**：審查支持請求和培訓問題
3. **起草更新**：創建帶原理的建議變更
4. **團隊審查**：從受影響的團隊成員獲得意見
5. **實施變更**：更新文檔並通知團隊
6. **監控採用**：跟蹤變更是否改善結果

活文檔原則：

單一真理來源：避免跨文檔重複信息
即時更新：當流程變更時更新文檔，而非按計劃
以用户為中心的組織：基於人們需要完成的事情構建，而非組織層次
漸進式透露：從要點開始，為需要的人鏈接到細節
反饋集成：讓用户容易建議改進

文檔工具和格式

對於內部團隊：

Wiki系統：容易協作和更新
版本控制文檔：保持文檔與代碼的一致性
交互式教程：帶驗證的逐步指南
視頻錄製：複雜程序的屏幕捕獲

對於開源/社區項目：

公共文檔站點：所有潛在貢獻者都可訪問
多語言：支持國際社區
社區可編輯：允許社區成員改進文檔
集成示例：展示如何與流行工具和平台集成

關鍵是從簡單開始，再根據您團隊的實際使用模式和反饋來擴展。用不上的文檔比沒有文檔更糟糕，因為它造成了什麼是當前的和什麼是準確的混淆。

11. 詳細操作程序

11.1 分支生命週期管理

分支狀態轉換流程

狀態轉換圖：

graph LR
    A[開發分支main] --> B[維護分支release/X.Y.x]
    B --> C[安全維護分支release/X.Y.x]  
    C --> D[歸檔分支archive/X.Y.x]
    D --> E[刪除分支]
    
    B --> F[hotfix/X.Y.Z-patch]
    F --> B

具體操作步驟

1. 維護分支到歸檔分支（處理GitHub分支重命名限制）

#!/bin/bash
# 由於GitHub不支持分支重命名，使用新分支創建方法
MAINTENANCE_BRANCH="release/1.1.x"
ARCHIVE_BRANCH="archive/1.1.x"

# 步驟1：創建歸檔分支
git checkout -b $ARCHIVE_BRANCH origin/$MAINTENANCE_BRANCH
git push origin $ARCHIVE_BRANCH

# 步驟2：更新分支保護規則（GitHub API）
curl -X PUT \
    -H "Authorization: token $GITHUB_TOKEN" \
    -H "Accept: application/vnd.github.v3+json" \
    "https://api.github.com/repos/owner/repo/branches/$ARCHIVE_BRANCH/protection" \
    -d '{
        "required_status_checks": null,
        "enforce_admins": true,
        "required_pull_request_reviews": null,
        "restrictions": {"users": [], "teams": [], "apps": []},
        "allow_force_pushes": false,
        "allow_deletions": false
    }'

# 步驟3：移除原分支保護規則
curl -X DELETE \
    -H "Authorization: token $GITHUB_TOKEN" \
    -H "Accept: application/vnd.github.v3+json" \
    "https://api.github.com/repos/owner/repo/branches/$MAINTENANCE_BRANCH/protection"

# 步驟4：刪除原維護分支
git push origin --delete $MAINTENANCE_BRANCH

# 步驟5：更新文檔和通知
echo "📝 請更新以下內容："
echo "  - README.md中的分支狀態表"
echo "  - CI/CD配置文件"
echo "  - 團隊Wiki文檔"

2. 緊急安全補丁多分支發佈

#!/bin/bash
# 安全補丁跨版本發佈流程
SECURITY_COMMIT="abc123def"
AFFECTED_BRANCHES=("release/2.0.x" "release/1.2.x")

for branch in "${AFFECTED_BRANCHES[@]}"; do
    echo "🔒 處理安全補丁：$branch"
    
    # 創建安全修復分支
    git checkout $branch
    git pull origin $branch
    git checkout -b "security-patch-$(date +%Y%m%d)-$branch"
    
    # 應用安全修復
    git cherry-pick -x $SECURITY_COMMIT
    
    # 如果出現衝突，暫停進行手動解決
    if [ $? -ne 0 ]; then
        echo "⚠️  檢測到衝突，請手動解決後繼續"
        read -p "衝突解決後按回車繼續..."
        git cherry-pick --continue
    fi
    
    # 推送安全分支
    git push origin "security-patch-$(date +%Y%m%d)-$branch"
    
    # 創建緊急PR
    gh pr create \
        --title "🚨 $branch 安全補丁" \
        --body "關鍵安全修復 - 需要加急審查" \
        --base "$branch" \
        --reviewer "security-team" \
        --label "security,urgent"
        
    echo "✅ $branch 安全補丁PR已創建"
done

11.2 CI/CD集成操作

自動化分支保護規則配置

# .github/workflows/branch-protection.yml
name: Setup Branch Protection
on:
  create:
    branches:
      - 'release/**'

jobs:
  setup-protection:
    runs-on: ubuntu-latest
    if: startsWith(github.ref, 'refs/heads/release/')
    steps:
      - name: Setup Release Branch Protection
        run: |
          BRANCH_NAME=${GITHUB_REF#refs/heads/}
          
          curl -X PUT \
            -H "Authorization: token ${{ secrets.GITHUB_TOKEN }}" \
            -H "Accept: application/vnd.github.v3+json" \
            "https://api.github.com/repos/${{ github.repository }}/branches/$BRANCH_NAME/protection" \
            -d '{
              "required_status_checks": {
                "strict": true,
                "contexts": ["ci/tests", "ci/regression-tests"]
              },
              "enforce_admins": true,
              "required_pull_request_reviews": {
                "required_approving_review_count": 1,
                "require_code_owner_reviews": true
              }
            }'

自動化版本發佈流程

# .github/workflows/release.yml
name: Automated Release
on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
      
      - name: Determine Release Type
        id: release-type
        run: |
          TAG_NAME=${GITHUB_REF#refs/tags/}
          VERSION=${TAG_NAME#v}
          
          # 判斷這是否是新維護分支版本
          if [[ $VERSION =~ ^[0-9]+\.[0-9]+\.0$ ]]; then
            echo "type=minor" >> $GITHUB_OUTPUT
            echo "branch=release/$(echo $VERSION | cut -d. -f1-2).x" >> $GITHUB_OUTPUT
          else
            echo "type=patch" >> $GITHUB_OUTPUT
          fi
      
      - name: Create Maintenance Branch
        if: steps.release-type.outputs.type == 'minor'
        run: |
          git checkout -b ${{ steps.release-type.outputs.branch }}
          git push origin ${{ steps.release-type.outputs.branch }}
      
      - name: Generate Release Notes
        run: |
          # 自動生成發佈説明
          ./scripts/generate-release-notes.sh ${{ github.ref_name }}
      
      - name: Create GitHub Release
        uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}
          body_path: ./release-notes.md
          draft: false
          prerelease: false

11.3 團隊協作操作標準

PR模板自動化

<!-- .github/pull_request_template.md -->
## 🔄 變更類型
- [ ] 🐛 錯誤修復
- [ ] ✨ 新功能
- [ ] ♻️  重構
- [ ] 📝 文檔更新
- [ ] 🚨 破壞性變更

## 📋 變更描述
此變更的內容和目的簡要描述

## 🧪 測試狀態
- [ ] 單元測試通過
- [ ] 集成測試通過  
- [ ] 手動測試完成
- [ ] 性能測試完成（如適用）

## 🔗 相關問題
Closes #
Relates to #

## 📸 截圖/視頻
<!-- 如果有UI變更，請提供截圖 -->

## ⚡ 性能影響
- [ ] 無性能影響
- [ ] 性能改進
- [ ] 性能退化（請解釋原因）

## 🔒 安全考慮
- [ ] 無安全影響
- [ ] 安全評估已完成
- [ ] 需要安全團隊審查

## 📚 文檔更新
- [ ] 不需要文檔更新
- [ ] API文檔已更新
- [ ] 用户文檔已更新
- [ ] 開發文檔已更新

## ✅ 審查檢查清單
### 代碼質量
- [ ] 代碼遵循項目標準
- [ ] 變量命名清晰
- [ ] 函數具有單一職責
- [ ] 異常處理完整

### 兼容性
- [ ] 向後兼容
- [ ] API兼容
- [ ] 數據庫兼容

### 安全
- [ ] 輸入驗證完成
- [ ] 權限控制正確
- [ ] 敏感數據處理安全

---
/assign @reviewer-team
/cc @stakeholder-team

分支清理自動化

# .github/workflows/branch-cleanup.yml  
name: Branch Cleanup
on:
  schedule:
    - cron: '0 2 * * 1'  # 每週一凌晨2點
  workflow_dispatch:

jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          fetch-depth: 0
          
      - name: Delete merged feature branches
        run: |
          # 刪除已合併的功能分支（保留最近30天）
          git branch -r --merged main | \
            grep -E 'origin/(feature|bugfix)/' | \
            grep -v HEAD | \
            sed 's/origin\///' | \
            while read branch; do
              # 檢查分支最後提交時間
              LAST_COMMIT=$(git log -1 --format=%ct origin/$branch)
              CUTOFF=$(date -d '30 days ago' +%s)
              
              if [ $LAST_COMMIT -lt $CUTOFF ]; then
                echo "刪除過時分支：$branch"
                git push origin --delete $branch
              fi
            done
      
      - name: Report stale branches
        run: |
          echo "📊 過時分支報告：" >> $GITHUB_STEP_SUMMARY
          git for-each-ref --format='%(refname:short) %(committerdate) %(authorname)' --sort=-committerdate refs/remotes/origin/ | \
            head -20 >> $GITHUB_STEP_SUMMARY

11.4 監控和告警

分支健康監控

#!/bin/bash
# scripts/branch-health-monitor.sh
# 定期檢查分支健康狀態並生成報告

WEBHOOK_URL="${SLACK_WEBHOOK_URL}"
REPO_NAME=$(basename -s .git `git config --get remote.origin.url`)

echo "🏥 啓動分支健康檢查..."

# 檢查分支差異
echo "## 分支狀態報告 - $(date)" > health-report.md

# 1. 檢查維護分支滯後狀態
echo "### 維護分支同步狀態" >> health-report.md
for branch in $(git branch -r | grep 'origin/release/' | sed 's/origin\///'); do
    AHEAD=$(git rev-list --count $branch..main)
    BEHIND=$(git rev-list --count main..$branch)
    
    if [ $BEHIND -gt 100 ]; then
        echo "⚠️  $branch：落後main $BEHIND 次提交" >> health-report.md
    elif [ $BEHIND -gt 50 ]; then
        echo "⚡ $branch：落後main $BEHIND 次提交" >> health-report.md  
    else
        echo "✅ $branch：同步良好（$BEHIND 次提交）" >> health-report.md
    fi
done

# 2. 檢查長期運行的PR
echo "### 長期運行的PR" >> health-report.md
gh pr list --state open --json number,title,createdAt,author | \
    jq -r '.[] | select((now - (.createdAt | strptime("%Y-%m-%dT%H:%M:%SZ") | mktime)) > (7*24*3600)) | "⏰ #\(.number): \(.title) (by \(.author.login))"' >> health-report.md

# 3. 發送Slack通知
if [ -n "$WEBHOOK_URL" ]; then
    REPORT_CONTENT=$(cat health-report.md)
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"📊 $REPO_NAME 分支健康報告\n\`\`\`$REPORT_CONTENT\`\`\`\"}" \
        $WEBHOOK_URL
fi

echo "📋 健康檢查完成，報告保存至 health-report.md"

發佈質量監控

#!/bin/bash
# scripts/release-quality-monitor.sh
# 監控發佈質量指標

echo "📈 發佈質量分析..."

# 1. 計算髮布頻率
RELEASES_LAST_MONTH=$(git tag --sort=-creatordate | head -10 | \
    xargs -I {} git log -1 --format="%ct" {} | \
    awk -v cutoff=$(date -d '30 days ago' +%s) '$1 > cutoff' | wc -l)

echo "過去30天的發佈數量：$RELEASES_LAST_MONTH"

# 2. 分析熱修復頻率
HOTFIXES_COUNT=$(git log --since="30 days ago" --grep="hotfix" --oneline | wc -l)
echo "熱修復數量：$HOTFIXES_COUNT"

# 3. 計算平均修復時間
echo "🐛 錯誤修復分析："
git log --since="30 days ago" --grep="fix" --format="%H %s %ct" | \
    head -10 | while read hash subject timestamp; do
        # 簡化修復時間計算（需要與問題跟蹤系統集成）
        echo "修復：$subject"
    done

# 4. 分支覆蓋分析
echo "🌿 分支覆蓋："
TOTAL_BRANCHES=$(git branch -r | wc -l)
ACTIVE_BRANCHES=$(git for-each-ref --format='%(committerdate)' --sort=-committerdate refs/remotes/origin/ | \
    awk -v cutoff=$(date -d '30 days ago' +%s) 'BEGIN{count=0} {cmd="date -d \""$1" "$2"\" +%s"; cmd | getline ts; close(cmd); if(ts > cutoff) count++} END{print count}')

echo "總分支數：$TOTAL_BRANCHES"  
echo "活躍分支數：$ACTIVE_BRANCHES"
echo "活躍比率：$(echo "scale=2; $ACTIVE_BRANCHES/$TOTAL_BRANCHES*100" | bc)%"

11.5 緊急響應程序

為什麼需要正式的緊急響應？

時間關鍵的決策制定：

減少高壓事件期間的混亂和延遲
確保緊急情況下的適當文檔記錄和溝通
防止可能造成額外問題的臨時解決方案
提供清晰的升級路徑和責任分配

風險管理：

在響應速度與維護質量標準之間取得平衡
確保在緊急情況下不忽視安全考慮
為事件後分析和學習提供審計線索
維持客户溝通和利益相關者管理

團隊協調：

事件期間明確的角色和責任
防止多人同時進行衝突的解決方案
確保知識共享並減少單點故障
在壓力狀況下維護團隊心理健康

生產事件響應框架

#!/bin/bash
# scripts/emergency-response.sh
# 目的：為處理生產緊急情況提供結構化方法
# 此腳本為關鍵事件響應提供指導和自動化

# 配置 - 根據您的環境進行定製
INCIDENT_ID=${1:-"INC-$(date +%Y%m%d-%H%M)"}
AFFECTED_VERSION=${2}
SEVERITY=${3:-"HIGH"}  # LOW, MEDIUM, HIGH, CRITICAL
DRY_RUN=${4:-false}

# 團隊通知渠道
EMERGENCY_SLACK_CHANNEL="#emergency-response"
STAKEHOLDER_EMAIL_LIST="stakeholders@company.com"
INCIDENT_TRACKER_URL="https://company.atlassian.net/browse/"

echo "🚨 初始化緊急響應協議"
echo "事件ID：$INCIDENT_ID"
echo "受影響版本：${AFFECTED_VERSION:-'待確定'}"
echo "嚴重程度：$SEVERITY"

# 步驟1：初始評估和設置
initialize_incident_response() {
    echo "📋 步驟1：事件響應初始化"
    
    # 創建事件跟蹤分支
    local incident_branch="incident/$INCIDENT_ID"
    
    if [[ "$DRY_RUN" != "true" ]]; then
        git checkout main
        git pull origin main
        git checkout -b "$incident_branch"
        git push origin "$incident_branch"
        echo "✅ 創建事件跟蹤分支：$incident_branch"
    else
        echo "DRY RUN：將創建分支 $incident_branch"
    fi
    
    # 創建事件文檔
    create_incident_documentation
    
    # 發送初始通知
    send_initial_notifications
}

create_incident_documentation() {
    local incident_doc="docs/incidents/$INCIDENT_ID.md"
    
    if [[ "$DRY_RUN" != "true" ]]; then
        mkdir -p "docs/incidents"
        
        cat > "$incident_doc" << EOF
# 生產事件報告 - $INCIDENT_ID

## 事件摘要
- **事件ID**：$INCIDENT_ID
- **開始時間**：$(date -u)
- **嚴重程度**：$SEVERITY
- **受影響版本**：${AFFECTED_VERSION:-'待確定'}
- **事件指揮官**：$(git config user.name)
- **狀態**：調查中

## 影響評估
### 用户影響
- [ ] 服務完全不可用
- [ ] 服務性能下降
- [ ] 特定功能問題
- [ ] 數據完整性擔憂
- [ ] 安全影響

### 業務影響
- [ ] 收入影響
- [ ] 面向客户的問題
- [ ] 合規擔憂
- [ ] 聲譽風險

## 技術細節
### 觀察到的症狀
[描述用户/監控系統正在經歷的情況]

### 受影響組件
[列出受影響的系統、服務或功能]

### 錯誤消息/日誌
\`\`\`
[粘貼相關錯誤消息或日誌條目]
\`\`\`

## 響應時間線
| 時間（UTC） | 行動 | 人員 | 結果 |
|------------|--------|---------|---------|
| $(date -u +"%H:%M") | 檢測到事件 | $(git config user.name) | 開始調查 |

## 立即採取的行動
- [ ] 檢查監控系統
- [ ] 審查最近部署
- [ ] 分析錯誤率和日誌
- [ ] 通知客户支持
- [ ] 警告利益相關者

## 調查説明
### 根本原因分析（進行中）
[記錄調查發現的發展情況]

### 潛在原因
- [ ] 最近的代碼變更
- [ ] 基礎設施問題
- [ ] 第三方服務問題
- [ ] 配置變更
- [ ] 數據庫問題
- [ ] 網絡/連接問題

## 響應策略
### 立即行動（接下來30分鐘）
- [ ] 如可能穩定服務
- [ ] 實施臨時解決方案
- [ ] 收集額外診斷信息
- [ ] 評估緊急部署需求

### 短期行動（接下來2-4小時）
- [ ] 開發永久修復
- [ ] 在暫存環境測試修復
- [ ] 準備緊急發佈
- [ ] 規劃部署和回滾程序

### 溝通計劃
- [ ] 內部團隊更新（每30分鐘）
- [ ] 利益相關者簡報（每小時）
- [ ] 客户溝通（根據需要）
- [ ] 事件後報告準備

## 修復開發
### 提議解決方案
[描述正在開發的修復]

### 測試策略
- [ ] 單元測試更新/添加
- [ ] 集成測試完成
- [ ] 安全審查（如適用）
- [ ] 性能影響評估

### 部署計劃
- [ ] 部署程序文檔化
- [ ] 回滾計劃準備
- [ ] 監控計劃建立
- [ ] 成功標準定義

## 解決後行動
### 立即（24小時內）
- [ ] 驗證服務恢復
- [ ] 更新監控告警
- [ ] 完成客户溝通
- [ ] 安排內部團隊彙報

### 後續（1周內）
- [ ] 完成事件後審查
- [ ] 識別流程改進
- [ ] 更新文檔
- [ ] 實施預防措施

## 經驗教訓
[解決後完成]

### 進展良好的方面
[響應的積極方面]

### 可以改進的方面
[改進領域]

### 行動項目
[防止再次發生的具體步驟]

---
**最後更新**：$(date -u) 由 $(git config user.name)
**事件狀態**：調查中
EOF

        git add "$incident_doc"
        git commit -m "docs: initialize incident report $INCIDENT_ID

Severity: $SEVERITY
Affected version: ${AFFECTED_VERSION:-'TBD'}
Commander: $(git config user.name)"
        
        git push origin "incident/$INCIDENT_ID"
        echo "✅ 創建事件文檔：$incident_doc"
    else
        echo "DRY RUN：將創建事件文檔"
    fi
}

send_initial_notifications() {
    echo "📢 發送初始事件通知..."
    
    # Slack通知
    if [[ -n "$SLACK_WEBHOOK_URL" ]] && [[ "$DRY_RUN" != "true" ]]; then
        local slack_color
        case "$SEVERITY" in
            "CRITICAL") slack_color="danger" ;;
            "HIGH") slack_color="warning" ;;
            *) slack_color="good" ;;
        esac
        
        curl -X POST -H 'Content-type: application/json' \
            --data "{
                \"channel\": \"$EMERGENCY_SLACK_CHANNEL\",
                \"text\": \"🚨 生產事件告警\",
                \"attachments\": [{
                    \"color\": \"$slack_color\",
                    \"title\": \"事件 $INCIDENT_ID - $SEVERITY\",
                    \"fields\": [
                        {\"title\": \"事件ID\", \"value\": \"$INCIDENT_ID\", \"short\": true},
                        {\"title\": \"嚴重程度\", \"value\": \"$SEVERITY\", \"short\": true},
                        {\"title\": \"受影響版本\", \"value\": \"${AFFECTED_VERSION:-'TBD'}\", \"short\": true},
                        {\"title\": \"指揮官\", \"value\": \"$(git config user.name)\", \"short\": true},
                        {\"title\": \"跟蹤分支\", \"value\": \"incident/$INCIDENT_ID\", \"short\": false}
                    ],
                    \"actions\": [{
                        \"type\": \"button\",
                        \"text\": \"查看文檔\",
                        \"url\": \"$INCIDENT_TRACKER_URL$INCIDENT_ID\"
                    }]
                }]
            }" \
            "$SLACK_WEBHOOK_URL"
    elif [[ "$DRY_RUN" == "true" ]]; then
        echo "DRY RUN：將發送Slack通知"
    fi
}

provide_response_guidance() {
    echo ""
    echo "🔧 緊急響應指導"
    echo "=============================="
    
    case "$SEVERITY" in
        "CRITICAL")
            echo "CRITICAL事件響應優先級："
            echo "1. 立即服務恢復（必要時接受技術債務）"
            echo "2. 每30分鐘利益相關者溝通"
            echo "3. 考慮回滾到最後已知良好版本"
            echo "4. 如需要繞過正常審查流程（需要文檔記錄）"
            echo "5. 全員參與 - 取消非必要會議"
            ;;
        "HIGH")
            echo "HIGH嚴重程度事件響應優先級："
            echo "1. 如可能4小時內修復"
            echo "2. 每小時利益相關者更新"
            echo "3. 加急審查流程（最低可行審查）"
            echo "4. 在開發永久修復時考慮臨時解決方案"
            ;;
        "MEDIUM")
            echo "MEDIUM嚴重程度事件響應優先級："
            echo "1. 工作日內修復"
            echo "2. 定期利益相關者更新（每4小時）"
            echo "3. 帶緊急標誌的標準審查流程"
            echo "4. 在修復開發同時專注根本原因分析"
            ;;
        "LOW")
            echo "LOW嚴重程度事件響應優先級："
            echo "1. 1-2個工作日內修復"
            echo "2. 標準溝通流程"
            echo "3. 正常審查和測試流程"
            echo "4. 強調適當的根本原因分析和預防"
            ;;
    esac
    
    echo ""
    echo "📋 接下來的立即步驟："
    echo "1. 用當前發現更新事件文檔"
    echo "2. 評估是否需要緊急部署"
    echo "3. 與團隊協調修復開發"
    echo "4. 設置定期更新計劃"
    echo "5. 監控進一步問題或升級"
}

# 主執行流程
main() {
    initialize_incident_response
    provide_response_guidance
    
    echo ""
    echo "✅ 緊急響應協議已初始化"
    echo ""
    echo "📋 重要提醒："
    echo "• 隨調查進展更新 docs/incidents/$INCIDENT_ID.md"
    echo "• 按嚴重程度計劃提供定期狀態更新"
    echo "• 首先專注恢復，其次根本原因分析"
    echo "• 記錄所有行動和決策以供事件後審查"
    echo "• 早期尋求幫助而非獨自奮鬥"
    echo ""
    echo "🌿 事件跟蹤分支：incident/$INCIDENT_ID"
    echo "📄 事件文檔：docs/incidents/$INCIDENT_ID.md"
}

# 執行前驗證
if [[ -z "$INCIDENT_ID" ]]; then
    echo "❌ 需要事件ID"
    exit 1
fi

# 執行緊急響應
main

事件嚴重程度指導原則

CRITICAL嚴重程度指標：

服務完全不可用
數據丟失或損壞
確認安全漏洞
收入影響 >$10K/小時（根據您的情況調整）
監管合規違規

HIGH嚴重程度指標：

主要功能不可用
嚴重性能下降
影響>20%用户的面向客户錯誤
支付/交易處理問題
數據完整性擔憂

MEDIUM嚴重程度指標：

次要功能問題
影響<20%用户的性能問題
非關鍵API端點失敗
關鍵用户流程中的表面問題
第三方集成問題

LOW嚴重程度指標：

文檔或幫助系統問題
非關鍵功能錯誤
非關鍵路徑中的性能問題
次要功能中的表面問題
開發或暫存環境問題

事件後流程

#!/bin/bash
# scripts/post-incident-review.sh
# 目的：在事件解決後促進學習和改進

INCIDENT_ID=${1}

if [[ -z "$INCIDENT_ID" ]]; then
    echo "用法：$0 <incident-id>"
    exit 1
fi

echo "📊 開始 $INCIDENT_ID 事件後審查"

# 生成事件時間線
generate_incident_timeline() {
    local incident_branch="incident/$INCIDENT_ID"
    local timeline_file="docs/incidents/${INCIDENT_ID}_timeline.md"
    
    echo "# 事件時間線 - $INCIDENT_ID" > "$timeline_file"
    echo "" >> "$timeline_file"
    
    # 從事件分支的git提交中提取時間線
    git log --format="%h|%ai|%an|%s" "$incident_branch" | \
        sort -t'|' -k2 | \
        while IFS='|' read hash timestamp author message; do
            echo "- **$(date -d "$timestamp" +'%H:%M')**：$message ($author)" >> "$timeline_file"
        done
    
    echo "✅ 時間線生成：$timeline_file"
}

# 創建事件後審查模板
create_review_template() {
    local review_file="docs/incidents/${INCIDENT_ID}_review.md"
    
    cat > "$review_file" << EOF
# 事件後審查 - $INCIDENT_ID

## 審查會議詳情
- **日期**：[待安排]
- **參與者**：[列出參會者]
- **持續時間**：[實際會議持續時間]
- **主持人**：[會議主持人]

## 事件摘要
[簡要總結髮生的事情]

## 影響分析
### 客户影響
- **受影響用户**：[數量/百分比]
- **持續時間**：[客户受影響多長時間]
- **服務級別**：[完全中斷、降級等]

### 業務影響
- **收入影響**：[估計財務影響]
- **客户滿意度**：[調查結果、投訴等]
- **合規/法律**：[任何監管影響]

## 響應有效性
### 進展良好的方面
1. [列出響應的積極方面]

### 可以改進的方面
1. [列出改進領域]

### 響應時間線分析
[針對此嚴重程度級別的目標響應時間進行審查]

## 根本原因分析
### 主要原因
[此事件發生的根本原因]

### 貢獻因素
1. [啓用或惡化事件的其他因素]

### 檢測和升級
[事件如何被發現和升級]

## 行動項目
| 行動 | 負責人 | 截止日期 | 狀態 |
|--------|-------|----------|--------|
| [具體改進行動] | [人員] | [日期] | 開放 |

## 流程改進
### 需要的文檔更新
- [ ] 更新事件響應程序
- [ ] 更新監控和告警
- [ ] 更新部署程序
- [ ] 更新培訓材料

### 技術改進
- [ ] 代碼變更以防止再次發生
- [ ] 基礎設施改進
- [ ] 監控增強
- [ ] 測試改進

### 流程改進
- [ ] 溝通流程更新
- [ ] 升級程序變更
- [ ] 培訓或技能發展需求
- [ ] 工具或自動化改進

## 經驗教訓
### 對於類似未來事件
[團隊下次應該記住什麼？]

### 對於流程演進
[我們的整體流程應該如何演進？]

---
**審查狀態**：[草稿/審查中/完成]
**後續日期**：[何時檢查行動項目進度]
EOF

    echo "✅ 審查模板創建：$review_file"
}

# 安排後續行動
schedule_followups() {
    echo "📅 安排後續行動..."
    
    # 創建日曆提醒（如果工具支持）
    echo "推薦後續計劃："
    echo "- 1周：檢查行動項目進度"
    echo "- 1個月：驗證預防措施有效"
    echo "- 3個月：審查事件模式和趨勢"
    echo "- 6個月：評估整體流程有效性"
}

# 主執行
generate_incident_timeline
create_review_template
schedule_followups

echo "🎉 事件後審查準備完成"
echo "後續步驟："
echo "1. 安排事件後審查會議"
echo "2. 邀請所有相關利益相關者"
echo "3. 在會議前完成審查模板"
echo "4. 專注學習，而非責備"
echo "5. 跟蹤行動項目直到完成"

此緊急響應框架在關鍵事件期間對速度的需求與適當文檔、溝通和學習的重要性之間取得了平衡。它應該根據您團隊處理事件的實際經驗進行測試和完善。

12. 快速參考手冊

🚀 常用命令快速參考

分支操作

# 創建並切換到新分支
git checkout -b feature/PROJ-123-new-feature

# 切換分支
git checkout main
git switch release/2.0.x

# 查看所有分支
git branch -a

# 刪除本地分支
git branch -d feature/completed-feature

# 刪除遠程分支
git push origin --delete feature/old-feature

合併操作

# 正常合併
git merge feature/my-feature

# 壓縮合並（適用於功能分支）
git merge --squash feature/my-feature

# 櫻桃選擇特定提交
git cherry-pick -x <commit-hash>

# 批量櫻桃選擇
git cherry-pick <start-hash>..<end-hash>

標籤管理

# 創建帶註釋的標籤
git tag -a v2.1.0 -m "Release version 2.1.0"

# 推送標籤到遠程
git push origin v2.1.0
git push origin --tags

# 查看標籤信息
git show v2.1.0

# 刪除標籤
git tag -d v2.1.0
git push origin --delete v2.1.0

狀態查看

# 查看當前狀態
git status

# 查看分支關係圖
git log --graph --oneline --all

# 查看文件變更歷史
git log -p filename

# 比較分支差異
git diff main..release/2.0.x

📋 工作流程檢查清單

功能開發

[ ] 從main創建功能分支
[ ] 遵循提交消息標準
[ ] 推送分支並創建PR
[ ] 通過代碼審查
[ ] 壓縮合併到main

錯誤修復

[ ] 確定修復目標分支
[ ] 創建錯誤修復分支
[ ] 修復並添加測試
[ ] 評估是否需要櫻桃選擇到其他分支
[ ] 合併到目標分支

發佈流程

[ ] 確認所有功能已合併
[ ] 創建發佈準備分支
[ ] 更新版本號和CHANGELOG
[ ] 執行預發佈測試
[ ] 創建發佈分支和標籤
[ ] 部署到生產環境

熱修復流程

[ ] 立即評估影響範圍
[ ] 從受影響分支創建熱修復分支
[ ] 快速修復問題
[ ] 執行緊急測試
[ ] 合併並立即發佈
[ ] 通知相關團隊

🏷️ 分支命名標準

分支類型	命名格式	示例
主分支	`main`	`main`
維護分支	`release/X.Y.x`	`release/2.1.x`
功能分支	`feature/[ID]-description`	`feature/PROJ-123-oauth-login`
修復分支	`bugfix/[ID]-description`	`bugfix/PROJ-456-memory-leak`
熱修復分支	`hotfix/version-description`	`hotfix/2.1.3-security-patch`
發佈準備	`release/prepare-version`	`release/prepare-2.2.0`

💬 提交消息格式

<type>(<scope>): <subject>

<body>

<footer>

提交類型

feat：新功能
fix：錯誤修復
docs：文檔更新
style：代碼格式
refactor：重構
perf：性能優化
test：測試
chore：構建/工具

提交示例

feat(auth): add JWT token validation

- Implement token expiration checking
- Add refresh token mechanism  
- Update API documentation

Closes: PROJ-123
Breaking Change: Remove session-based auth

🏆 最佳實踐

分支管理

✅ 推薦實踐

保持分支名稱簡潔明瞭
及時刪除已合併的功能分支
定期同步上游分支
使用PR進行代碼審查

❌ 避免這些

功能分支的長期維護
直接推送到main分支
跳過代碼審查流程
忽略合併衝突

提交管理

✅ 推薦實踐

提交消息清晰描述變更
每個提交包含完整功能
提交前運行本地測試
使用-x參數記錄櫻桃選擇來源

❌ 避免這些

過於簡單的提交消息（"修復bug"）
提交包含無關文件
提交未測試的代碼
頻繁無意義提交

發佈管理

✅ 推薦實踐

遵循語義版本控制標準
維護詳細的CHANGELOG
執行完整發布檢查清單
建立回滾應急計劃

❌ 避免這些

任意版本號跳躍
省略發佈測試步驟
缺失版本發佈文檔
沒有回滾策略

🆘 常見問題解決

合併衝突處理

# 1. 拉取最新代碼
git fetch origin

# 2. 合併目標分支
git merge origin/main

# 3. 手動解決衝突
# 編輯衝突文件，解決 <<<< ==== >>>> 標記

# 4. 標記衝突已解決
git add resolved-file.js

# 5. 完成合並
git commit

錯誤提交撤銷

# 撤銷最後一次提交（保留變更）
git reset HEAD~1

# 撤銷最後一次提交（丟棄變更）
git reset --hard HEAD~1

# 修改最後一次提交消息
git commit --amend -m "New commit message"

# 撤銷已推送的提交
git revert <commit-hash>

分支同步更新

# 同步遠程分支信息
git fetch --prune

# 更新當前分支
git pull origin current-branch

# 將main分支更新合併到功能分支
git checkout feature/my-feature
git merge main

📞 獲取幫助

內部資源

Git管理策略文檔：docs/git-strategy.md
團隊培訓材料：docs/training/
自動化腳本：scripts/

外部資源

聯繫信息

技術支持：tech-support@company.com
發佈管理：release-team@company.com
緊急情況：#devops-emergency Slack頻道

嚴重程度升級路徑

嚴重程度	響應時間	通知頻率	升級條件
LOW	2個工作日	每日更新	3天無進展
MEDIUM	1個工作日	每4小時	1天無進展
HIGH	4小時	每小時	6小時無進展
CRITICAL	30分鐘	每30分鐘	2小時無進展

工具和資源鏈接

Git GUI工具：

自動化和CI/CD：

監控和告警：

文檔版本：v1.0
最後更新：2025年
維護者：開發運維團隊
審查週期：季度

vistart 動態日志

@vistart

標簽

Python (289)

go (184)

Git (53)

Ubuntu (44)

多線程 (43)

優化 (32)

框架 (31)

協程 (27)

函數 (25)

orm (24)

異步 (23)

調試 (18)

動態

完整Git版本管理策略 - 動態 詳情

策略概述

1. 分支模型架構

1.1 核心分支系統

1.2 支持分支系統

1.3 分支命名約定

2. 版本號管理標準

2.1 版本編號標準

標準語義版本控制（SemVer）

特定語言版本標準

2.2 版本生命週期

2.3 版本策略指導原則

應用軟件策略

框架/庫軟件策略

混合策略考慮

3. 分支保護策略

3.1 分支保護規則模板

模板A：大型團隊/企業設置

模板B：小團隊/初創公司設置

模板C：開源項目

3.2 定製指導原則

3.3 合併策略

4. 開發工作流程

4.1 功能開發工作流程

4.2 Bug修復工作流程

4.3 熱修復工作流程

5. 發佈管理流程

5.1 常規發佈流程

5.2 發佈檢查清單模板

模板A：Web應用程序發佈檢查清單

模板B：庫/框架發佈檢查清單

模板C：移動應用程序發佈檢查清單

模板D：微服務發佈檢查清單

6. 跨版本維護策略

6.1 安全補丁傳播

安全補丁回傳流程

為什麼推薦手動流程

團隊推薦工作流程

6.2 Bug修復評估矩陣

何時可能考慮EOL修復：

EOL修復決策框架：

行業示例：

重要免責聲明：

溝通策略：

6.3 櫻桃選擇最佳實踐

逐步櫻桃選擇過程

異常處理原則

櫻桃選擇後驗證

批量櫻桃選擇指導原則

要避免的常見陷阱

緊急櫻桃選擇協議

7. 自動化工具配置

7.1 CI/CD流水線配置

為什麼為分支管理自動化CI/CD？

帶理由的配置模板

項目特定適應

7.2 版本自動化腳本

為什麼自動化版本管理？

帶決策邏輯的實現

項目特定定製

7.3 分支保護自動化

為什麼自動化分支保護？

實現策略

項目類型考慮

完整Git版本管理策略 - 動態詳情