---
source: ../../core/git-workflow.md
source_version: 1.3.0
translation_version: 1.3.0
last_synced: 2026-01-24
status: current
---

# Git 工作流程標準

> **語言**: [English](../../../../core/git-workflow.md) | 繁體中文

**版本**: 1.3.0
**最後更新**: 2026-01-24
**適用範圍**: 所有使用 Git 版本控制的專案

---

## 目的

本標準定義 Git 分支策略與工作流程，確保團隊與專案間的一致、可預測的協作模式。

---

## 工作流程策略選擇

**專案必須選擇一種**工作流程策略並明確記錄。

### 決策樹

使用此流程圖來選擇適當的工作流程：

```
                    ┌─────────────────────────────────────┐
                    │ How often do you deploy to         │
                    │ production?                        │
                    │ 您多常部署到正式環境？                │
                    └───────────────┬─────────────────────┘
                                    │
            ┌───────────────────────┼───────────────────────┐
            ▼                       ▼                       ▼
   ┌────────────────┐    ┌────────────────┐    ┌────────────────┐
   │ Multiple times │    │ Weekly to      │    │ Monthly or     │
   │ per day        │    │ bi-weekly      │    │ longer         │
   │ 每天多次        │    │ 每週或雙週      │    │ 每月或更久      │
   └───────┬────────┘    └───────┬────────┘    └───────┬────────┘
           │                     │                     │
           ▼                     ▼                     ▼
   ┌────────────────┐    ┌────────────────┐    ┌────────────────┐
   │ Trunk-Based    │    │ GitHub Flow    │    │ GitFlow        │
   │ Development    │    │                │    │                │
   └────────────────┘    └────────────────┘    └────────────────┘
```

### 選擇矩陣

| 因素 | GitFlow | GitHub Flow | Trunk-Based |
|------|---------|-------------|-------------|
| **發布頻率** | 每月以上 | 每週 | 每天多次 |
| **團隊規模** | 大型 (10+) | 中型 (5-15) | 小到中型 (3-10) |
| **CI/CD 成熟度** | 基礎 | 中等 | 進階 |
| **功能開關** | 選用 | 選用 | 必需 |
| **緊急修復流程** | 專用分支 | 與功能相同 | 與功能相同 |
| **複雜度** | 高 | 低 | 中 |

### 快速選擇指南

**選擇 GitFlow 當**:
- 您有固定的發布週期（每月、每季）
- 您同時維護多個正式版本
- 您有獨立的開發團隊和發布管理團隊

**選擇 GitHub Flow 當**:
- 您每週或按需部署到正式環境
- 您只有單一正式版本
- 您想要簡單且有良好追溯性的流程

**選擇 Trunk-Based 當**:
- 您有成熟的 CI/CD 和自動化測試
- 您的團隊實踐持續整合
- 您習慣使用功能開關控制未完成的功能

### 工作流程選擇流程

**誰來決定**：技術主管或工程經理，與團隊協商。

**何時決定**：

| 專案階段 | 動作 |
|---------|------|
| 專案啟動 | 根據團隊規模和發布計畫選擇初始工作流程 |
| 第一次發布 | 審查並確認選擇；鎖定至少一個發布週期 |
| 重大團隊變動 | 如果團隊規模翻倍或減半，重新評估 |
| 發布節奏變更 | 如果從每月改為每週或反之，重新評估 |

**如何記錄**：

1. **記錄在專案 README** 或 CONTRIBUTING.md 中：
   ```markdown
   ## Git 工作流程
   本專案使用 **GitHub Flow**。
   - 決定日期：2025-01-15
   - 決定者：@techlead
   - 理由：每週部署，單一正式版本
   ```

2. **設定分支保護**規則以強制執行所選的工作流程。

3. **更新新人入職文件**以參考工作流程選擇。

**變更工作流程**：工作流程變更應視為破壞性變更。至少提前一個衝刺週期宣布，並提供遷移文件。

---

## 策略 A: GitFlow

**最適合**:
定期發布（每月、每季）、同時維護多個正式版本、開發與正式環境明確分離、大型團隊與正式發布流程

### 分支結構

```
main          ─●────────●─────────●── (Production releases: v1.0, v2.0)
               ╱          ╲         ╲
develop   ────●────●──────●─────────●── (Development mainline)
             ╱      ╲      ╲
feature/*  ─●────────●      ╲  (Feature branches)
                              ╲
release/*                      ●───● (Release preparation)
                                   ╱
hotfix/*                      ────● (Emergency fixes)
```

### 分支類型

| 分支類型 | 目的 | 基礎分支 | 合併目標 | 生命週期 |
|---------|------|---------|----------|---------|
| `main` | 正式環境程式碼 | - | - | 永久 |
| `develop` | 整合分支 | - | - | 永久 |
| `feature/*` | 新功能 | `develop` | `develop` | 暫時 |
| `release/*` | 發布準備 | `develop` | `main` + `develop` | 暫時 |
| `hotfix/*` | 緊急修復 | `main` | `main` + `develop` | 暫時 |

### 工作流程步驟

#### 1. 功能開發

```bash
# Create feature branch from develop
git checkout develop
git pull origin develop
git checkout -b feature/oauth-login

# Work on feature
git add .
git commit -m "feat(auth): add OAuth2 login"

# Push to remote
git push -u origin feature/oauth-login

# Create pull request to develop
# After review approval, merge to develop
git checkout develop
git merge --no-ff feature/oauth-login
git push origin develop

# Delete feature branch
git branch -d feature/oauth-login
git push origin --delete feature/oauth-login
```

#### 2. 發布準備

> **變更日誌更新**：將 `[Unreleased]` 的條目移至新版本區段並加上發布日期。詳細指南請參閱 [changelog-standards.md](../../../../core/changelog-standards.md)。

```bash
# Create release branch from develop
git checkout develop
git pull origin develop
git checkout -b release/v1.2.0

# Prepare release (version bump, changelog, etc.)
# 1. Update CHANGELOG.md: move [Unreleased] to [1.2.0] - YYYY-MM-DD
# 2. Update version in package.json (or equivalent)
npm version 1.2.0
git add package.json CHANGELOG.md
git commit -m "chore(release): prepare v1.2.0"

# Merge to main
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "Release version 1.2.0"
git push origin main --tags

# Merge back to develop
git checkout develop
git merge --no-ff release/v1.2.0
git push origin develop

# Delete release branch
git branch -d release/v1.2.0
git push origin --delete release/v1.2.0
```

#### 3. 緊急修復

```bash
# Create hotfix branch from main
git checkout main
git pull origin main
git checkout -b hotfix/critical-security-fix

# Fix the issue
git add .
git commit -m "fix(security): patch SQL injection vulnerability"

# Merge to main
git checkout main
git merge --no-ff hotfix/critical-security-fix
git tag -a v1.2.1 -m "Hotfix version 1.2.1"
git push origin main --tags

# Merge to develop
git checkout develop
git merge --no-ff hotfix/critical-security-fix
git push origin develop

# Delete hotfix branch
git branch -d hotfix/critical-security-fix
git push origin --delete hotfix/critical-security-fix
```

---

## 策略 B: GitHub Flow

**最適合**:
持續部署、Web 應用程式、中小型團隊、快速迭代週期

### 分支結構

```
main      ────●─────────●──────●── (Always deployable)
               ╲         ╱      ╱
feature/*       ●───●───●      ╱  (Feature + PR)
                              ╱
bugfix/*                 ────●  (Bug fixes)
```

### 分支類型

| 分支類型 | 目的 | 基礎分支 | 合併目標 | 生命週期 |
|---------|------|---------|----------|---------|
| `main` | 正式環境程式碼 | - | - | 永久 |
| `feature/*` | 新功能 | `main` | `main` | 暫時 |
| `bugfix/*` | Bug 修復 | `main` | `main` | 暫時 |
| `hotfix/*` | 緊急修復 | `main` | `main` | 暫時 |

### 工作流程步驟

```bash
# 1. Create feature branch from main
git checkout main
git pull origin main
git checkout -b feature/user-profile

# 2. Work and commit frequently
git add .
git commit -m "feat(profile): add avatar upload"
git push -u origin feature/user-profile

# 3. Open pull request to main
# Use GitHub/GitLab UI to create PR

# 4. After CI passes and review approval, merge to main
# (Usually done via GitHub/GitLab UI with "Squash and merge")

# 5. Deploy main to production
git checkout main
git pull origin main
# Trigger deployment pipeline

# 6. Delete feature branch (auto-deleted by GitHub/GitLab)
```

### 關鍵原則

1. **`main` 永遠可部署**
2. **從 `main` 分支**
3. **透過 PR 合併到 `main`**
4. **合併後立即部署**

---

## 策略 C: Trunk-Based Development

**最適合**:
成熟的 CI/CD 管道、高信任度且經驗豐富的團隊、頻繁整合（每天多次）、使用功能開關控制未完成功能

### 分支結構

```
main  ────●─●─●─●─●─●─●──► (Single long-lived branch)
           ╲│╱ ╲│╱ ╲│╱
feature/*   ●   ●   ●  (Very short-lived, ≤2 days)
```

### 分支類型

| 分支類型 | 目的 | 基礎分支 | 合併目標 | 生命週期 |
|---------|------|---------|----------|---------|
| `main` | 主幹 | - | - | 永久 |
| `feature/*` | 小型變更 | `main` | `main` | ≤2 天 |

### 工作流程步驟

```bash
# 1. Create short-lived branch
git checkout main
git pull origin main
git checkout -b feature/add-validation

# 2. Make small, atomic change
git add .
git commit -m "feat(validation): add email format check"

# 3. Push and create PR (same day)
git push -u origin feature/add-validation

# 4. Merge quickly after review (within hours)
# Prefer rebase to keep linear history
git checkout main
git pull origin main
git rebase main feature/add-validation
git checkout main
git merge --ff-only feature/add-validation
git push origin main

# 5. Delete branch immediately
git branch -d feature/add-validation
git push origin --delete feature/add-validation
```

### 關鍵原則

1. **頻繁整合**（每天多次）
2. **保持分支短命**（≤2 天）
3. **使用功能開關**控制未完成功能
4. **自動化一切**（測試、建置、部署）

---

## Trunk-Based Development 與功能開關

### 為何功能開關不可或缺

功能開關使 trunk-based development 能夠將**部署**與**發布**解耦：

```
┌─────────────────────────────────────────────────────────────────┐
│                       程式碼生命週期                              │
├─────────────────────────────────────────────────────────────────┤
│   合併到 main      部署到正式環境      對使用者啟用               │
│      │                 │                   │                     │
│      ▼                 ▼                   ▼                     │
│   ┌─────────┐      ┌─────────┐        ┌─────────┐              │
│   │  提交   │─────►│  部署   │───────►│  發布   │              │
│   │ (程式碼) │      │ (二進位) │        │ (使用者) │              │
│   └─────────┘      └─────────┘        └─────────┘              │
│                         └────── 功能開關 ──────┘                 │
│                              (解耦)                              │
└─────────────────────────────────────────────────────────────────┘
```

### 功能開關生命週期

| 階段 | 開關狀態 | 動作 |
|------|---------|------|
| 開發 | 關閉 | 程式碼已合併但隱藏 |
| 內部測試 | 對團隊開啟 | QA 和 dogfooding |
| Beta | 對 beta 使用者開啟 | 收集回饋 |
| 逐步推出 | 1% → 10% → 50% → 100% | 監控指標 |
| 完整發布 | 對所有人開啟 | 預設行為 |
| 清理 | 移除開關 | 技術債清理 |

---

## Ship/Show/Ask 決策模型

### 概述

並非所有變更都需要相同的審查流程。Ship/Show/Ask 模型幫助團隊決定：

| 模式 | 說明 | 適用時機 |
|------|------|---------|
| **SHIP** | 直接推送到 main | 低風險、高信心 |
| **SHOW** | 合併後通知團隊 | 中等風險、需要知會 |
| **ASK** | 開 PR，等待審批 | 高風險、需要討論 |

### 何時 Ship（直接推送）

- 文件中的錯字修正
- 新增除錯日誌
- 更新依賴（CI 通過時）
- 明顯的 bug 修復（有測試）

### 何時 Ask（PR 加阻塞審查）

- 架構決策
- 重大變更
- 安全敏感程式碼
- 共用函式庫的變更

---

## 堆疊式 PR 工作流程

### 什麼是堆疊式 PR？

堆疊式 PR 將大型功能拆分為可漸進審查的較小、相依的 pull request：

```
main ────●─────────────────────────────────────────►
          ╲
           PR #1 (資料庫 schema) ────●
                                      ╲
                                       PR #2 (API) ────●
                                                        ╲
                                                   PR #3 (UI) ●
```

### 何時使用堆疊式 PR

| 情境 | 推薦使用堆疊式 PR |
|------|-----------------|
| 功能 > 500 行 | ✅ 是 |
| 多個邏輯元件 | ✅ 是 |
| 需要早期回饋 | ✅ 是 |
| 簡單 bug 修復 | ❌ 否，使用單一 PR |

---

## 傳統式 PR 標題

### 格式

PR 標題應遵循與 commit 訊息相同的格式：

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

### 類型參考

| 類型 | 用途 | 範例 |
|------|------|------|
| `feat` | 新功能 | `feat(auth): 新增 OAuth2 登入` |
| `fix` | Bug 修復 | `fix(api): 處理空值回應` |
| `docs` | 文件 | `docs(readme): 更新安裝步驟` |
| `refactor` | 重構 | `refactor(utils): 抽取驗證邏輯` |
| `test` | 新增測試 | `test(auth): 新增登入單元測試` |
| `chore` | 維護 | `chore(deps): 更新 lodash 到 4.17.21` |

### 重大變更

用 `!` 在類型後面表示重大變更：

```
feat(api)!: 變更使用者端點的回應格式
```

---

## 開新分支前檢查清單

開始新功能開發前，完成以下檢查以避免常見問題。

### 適用於 GitFlow 和 GitHub Flow

#### 1. 確認無未合併分支

```bash
git branch --no-merged main
# For GitFlow, also check:
git branch --no-merged develop
```

- **如有未合併分支，必須先處理**（合併或關閉）
- **禁止在有未合併分支的情況下開新功能分支**

#### 2. 同步最新程式碼

```bash
git checkout main  # or develop for GitFlow
git pull origin main
```

#### 3. 確認測試通過

```bash
# Run your project's test suite
npm test        # Node.js
pytest          # Python
./gradlew test  # Java/Kotlin
```

#### 4. 建立分支

```bash
git checkout -b feature/description
```

### 為什麼重要

| 跳過檢查的後果 | 影響 |
|--------------|------|
| 修復散落各處 | `main` 仍有 bug |
| 功能互相依賴 | 新分支缺少前一個功能的程式碼 |
| 合併順序混亂 | 衝突變多、歷史難追蹤 |
| 測試不完整 | 每個分支只測自己的部分 |

### 適用於 Trunk-Based Development

Trunk-Based Development 因其短命分支特性（≤2 天）有**不同的要求**：

| 檢查項目 | 適用性 | 說明 |
|---------|-------|------|
| 確認無未合併分支 | ⚠️ **較不適用** | 設計上分支不應存在超過 2 天 |
| 同步最新程式碼 | ✅ **關鍵** | 因頻繁整合，更為重要 |
| 確認測試通過 | ✅ **關鍵** | 自動化是此工作流程的核心 |

**關鍵差異**：若在 Trunk-Based Development 中有超過 2 天的未合併分支，這本身就違反了工作流程原則。重點應放在**頻繁整合**而非檢查未合併分支。

---

## 分支命名慣例

### 標準格式

```
<type>/<short-description>
```

### 類型

| 類型 | 用途 | 範例 |
|------|------|------|
| `feature/` | 新功能 | `feature/oauth-login` |
| `fix/` 或 `bugfix/` | Bug 修復 | `fix/memory-leak` |
| `hotfix/` | 緊急正式環境修復 | `hotfix/security-patch` |
| `refactor/` | 程式碼重構 | `refactor/extract-service` |
| `docs/` | 僅文件更新 | `docs/api-reference` |
| `test/` | 測試新增 | `test/integration-tests` |
| `chore/` | 維護任務 | `chore/update-dependencies` |
| `release/` | 發布準備 (僅 GitFlow) | `release/v1.2.0` |

### 命名規則

1. **使用小寫**
2. **使用連字號分隔單詞**
3. **具描述性但簡潔**
4. **避免僅用 issue 編號**

**良好範例**:
```
feature/user-authentication
fix/null-pointer-in-payment
hotfix/critical-data-loss
refactor/database-connection-pool
docs/update-installation-guide
```

**不良範例**:
```
feature/123                    # ❌ 沒有描述性
Fix-Bug                        # ❌ 非小寫，過於籠統
feature/add_new_feature        # ❌ 使用底線，過於籠統
myFeature                      # ❌ 駝峰式命名，無類型前綴
```

---

## 合併策略

**專案必須為每種分支類型選擇一種**。

### 選項 1: 合併提交 (--no-ff)

**保留分支歷史**

```bash
git merge --no-ff feature/user-auth
```

**優點**:
- ✅ 完整保留歷史
- ✅ 易於還原整個功能
- ✅ 清楚的功能邊界

**缺點**:
- ❌ Git 日誌雜亂
- ❌ 複雜的圖形視覺化

**最適合**: GitFlow、長期功能分支

---

### 選項 2: 壓縮合併

**將所有提交合併為一個**

```bash
git merge --squash feature/user-auth
git commit -m "feat(auth): add user authentication"
```

**優點**:
- ✅ 乾淨、線性的歷史
- ✅ 每個功能一個提交
- ✅ 易於閱讀的 git 日誌

**缺點**:
- ❌ 失去詳細歷史
- ❌ 無法精選個別提交

**最適合**: GitHub Flow、功能分支

---

### 選項 3: 變基與快轉

**在目標分支上重播提交**

```bash
git rebase main feature/user-auth
git checkout main
git merge --ff-only feature/user-auth
```

**優點**:
- ✅ 線性、乾淨的歷史
- ✅ 保留個別提交
- ✅ 無合併提交

**缺點**:
- ❌ 改寫歷史（不要用於共享分支）
- ❌ 解決衝突可能繁瑣

**最適合**: Trunk-Based Development、短期分支

---

## 衝突解決

### 預防

1. **頻繁同步**
   ```bash
   git checkout main
   git pull origin main
   git checkout feature/my-feature
   git merge main  # or git rebase main
   ```

2. **保持分支小型化**
   - 避免長期功能分支
   - 將大型功能拆分為小型 PR

3. **溝通**
   - 宣告重大重構
   - 協調共享檔案的修改

### 解決步驟

```bash
# 1. Attempt merge
git checkout main
git pull origin main
git checkout feature/my-feature
git merge main

# 2. Conflicts occur - Git marks them in files
# Open files and resolve conflicts:
# <<<<<<< HEAD
# Current branch changes
# =======
# Incoming changes
# >>>>>>> main

# 3. After resolving, stage files
git add resolved-file.js

# 4. Complete the merge
git commit -m "chore: resolve merge conflicts with main"

# 5. Test thoroughly
npm test

# 6. Push
git push origin feature/my-feature
```

---

## 標籤與發布

### 語義化版本

遵循 [Semantic Versioning 2.0.0](https://semver.org/):

```
MAJOR.MINOR.PATCH

例如: v2.3.1
```

- **MAJOR**: 重大變更（不相容的 API 變更）
- **MINOR**: 新功能（向後相容）
- **PATCH**: Bug 修復（向後相容）

### 建立標籤

```bash
# Annotated tag (recommended)
git tag -a v1.2.0 -m "Release version 1.2.0: Add OAuth2 support"

# Push tag to remote
git push origin v1.2.0

# Push all tags
git push origin --tags

# List tags
git tag -l
```

### 預發布版本

```
v1.2.0-alpha.1      # Alpha release
v1.2.0-beta.2       # Beta release
v1.2.0-rc.1         # Release candidate
```

---

## 保護分支

設定分支保護規則：

### 建議的 `main`/`develop` 保護:

- ✅ **需要 pull request 審查** (1-2 位審查者)
- ✅ **需要狀態檢查通過** (CI 測試、linting)
- ✅ **需要分支保持最新** 才能合併
- ✅ **管理員也受限制**
- ❌ **不允許強制推送**
- ❌ **不允許刪除**

**設定範例 (GitHub)**:
```
Settings → Branches → Branch protection rules

Rule: main
☑ Require pull request before merging
  ☑ Require approvals: 1
☑ Require status checks before merging
  ☑ Require branches to be up to date
  ☑ Status checks: CI/Build, Lint, Tests
☑ Do not allow bypassing the above settings
☐ Allow force pushes
☐ Allow deletions
```

---

## Pull Request 工作流程

### PR 建立檢查清單

- [ ] **標題遵循提交慣例** (例如 `feat(auth): add OAuth2`)
- [ ] **描述說明原因** (不只是做了什麼)
- [ ] **連結到 issue** (例如 "Closes #123")
- [ ] **新功能包含測試**
- [ ] **必要時更新文件**
- [ ] **在描述中標示重大變更**
- [ ] **UI 變更包含截圖/GIF**

### PR 描述範本

```markdown
## What

[簡短描述此 PR 做了什麼]

## Why

[說明為什麼需要此變更]

## Changes

- [主要變更的條列清單]
- [用 ⚠️ 標記重大變更]

## Testing

- [ ] 已新增/更新單元測試
- [ ] 整合測試通過
- [ ] 已執行手動測試

## Screenshots (if applicable)

[為 UI 變更新增截圖]

## Related Issues

Closes #123
Refs #456
```

---

## Git 指令參考

### 日常操作

```bash
# Check status
git status

# View changes
git diff
git diff --staged

# Stage changes
git add file.js
git add .

# Commit
git commit -m "feat: add feature"

# Push
git push origin feature/my-feature

# Pull latest
git pull origin main

# View history
git log --oneline --graph --all
```

### 分支操作

```bash
# List branches
git branch -a

# Create branch
git checkout -b feature/new-feature

# Switch branch
git checkout main

# Delete local branch
git branch -d feature/old-feature

# Delete remote branch
git push origin --delete feature/old-feature

# Rename branch
git branch -m old-name new-name
```

### 進階操作

```bash
# Stash changes
git stash
git stash pop

# Cherry-pick commit
git cherry-pick <commit-hash>

# Revert commit
git revert <commit-hash>

# Reset to previous commit (dangerous!)
git reset --hard <commit-hash>

# Amend last commit
git commit --amend

# Interactive rebase (clean up commits)
git rebase -i HEAD~3
```

---

## 專案設定範本

在 `CONTRIBUTING.md` 中記錄您的工作流程：

```markdown
## Git Workflow

### Branching Strategy
This project uses **[GitFlow / GitHub Flow / Trunk-Based Development]**.

### Branch Types
- `main`: Production code
- `develop`: Development mainline (GitFlow only)
- `feature/*`: New features
- `fix/*`: Bug fixes
- `hotfix/*`: Urgent production fixes

### Branch Naming
Format: `<type>/<description>`
Example: `feature/oauth-login`, `fix/memory-leak`

### Merge Strategy
- Feature branches: **[Squash / Merge commit / Rebase]**
- Release branches: Merge commit (--no-ff)
- Hotfix branches: Merge commit (--no-ff)

### Protected Branches
- `main`: Requires 1 review, CI must pass
- `develop`: Requires 1 review (if using GitFlow)

### Pull Request Process
1. Create branch from `[main/develop]`
2. Make changes and push
3. Open PR with description
4. Wait for review approval
5. Ensure CI passes
6. Merge using **[strategy]**
```

---

## 疑難排解

### 不小心提交到錯誤的分支

```bash
# Undo last commit but keep changes
git reset --soft HEAD~1

# Switch to correct branch
git checkout correct-branch

# Commit changes
git add .
git commit -m "feat: add feature"
```

### 需要從 main 更新分支

```bash
# Option 1: Merge (preserves history)
git checkout feature/my-feature
git merge main

# Option 2: Rebase (cleaner history)
git checkout feature/my-feature
git rebase main
```

### 不小心強制推送到保護分支

```bash
# ⚠️ Contact team immediately
# ⚠️ Check if branch protection was enabled
# ⚠️ Restore from reflog if needed:
git reflog
git reset --hard <previous-commit-hash>
```

---

## 相關標準

- [Commit Message Guide](../../../../core/commit-message-guide.md) - Commit 訊息規範
- [Code Check-in Standards](../../../../core/checkin-standards.md) - 程式碼簽入標準
- [Versioning Standard](../../../../core/versioning.md) - 語義化版本標準
- [Changelog Standards](../../../../core/changelog-standards.md) - 變更日誌標準

---

## 版本歷史

| 版本 | 日期 | 變更 |
|------|------|------|
| 1.3.0 | 2026-01-24 | 新增：Trunk-Based + 功能開關整合、Ship/Show/Ask 決策模型、堆疊式 PR、傳統式 PR 標題 |
| 1.2.1 | 2025-12-24 | 新增：相關標準區段 |
| 1.2.0 | 2025-12-16 | 新增：工作流程策略決策樹、選擇矩陣和快速選擇指南 |
| 1.1.0 | 2025-12-08 | 新增：開分支前檢查清單區段，含工作流程特定指引 |
| 1.0.0 | 2025-11-12 | 初始 Git 工作流程標準 |

---

## 參考資料

- [GitFlow Original Article](https://nvie.com/posts/a-successful-git-branching-model/)
- [GitHub Flow Guide](https://guides.github.com/introduction/flow/)
- [Trunk-Based Development](https://trunkbaseddevelopment.com/)
- [Semantic Versioning](https://semver.org/)
- [Ship/Show/Ask](https://martinfowler.com/articles/ship-show-ask.html) - Rouan Wilsenach 的程式碼變更決策模型
- [功能開關最佳實踐](https://launchdarkly.com/blog/best-practices-feature-flags/) - LaunchDarkly 的全面指南
- [堆疊式 Diffs](https://graphite.dev/guides/stacked-diffs) - Graphite 的堆疊式 PR 工作流程指南
- [傳統式 Commits](https://www.conventionalcommits.org/) - Commit 訊息規範

---

## 授權

本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
