Git 團隊開發分支更新策略教學

策略 A：全部使用 Merge（穩定保守型）

操作規則

Feature 分支更新：

1
git merge main

PR 合併至 main：

1
git merge feature-branch
  • 不改寫歷史
  • 不使用 rebase
  • 不使用 force push

Commit Graph 示意

開發前
main:    A──B──C
               \
feature:        D──E
feature 更新 main（merge）
main:    A──B──C
               \     \
feature:        D──E───M

M = merge commit（有兩個 parent）

PR 合併回 main
main:    A──B──C──────────M2
               \         /
feature:        D──E───M

特性

  • 會產生 merge commit
  • Commit graph 有分支線
  • 歷史完整保留
  • 安全性高

適用情境

  • 團隊 Git 熟練度不一致
  • 長期維護專案
  • 對歷史可追溯性要求高

策略 B：Feature Rebase + PR Merge（歷史整潔型）

操作規則

Feature 分支更新：

1
git rebase main

PR 合併至 main（建議 merge commit 或 squash）：

1
git merge feature-branch

Commit Graph 示意

開發前
main:    A──B──C
               \
feature:        D──E
feature rebase main
main:    A──B──C
                     \
feature:              D'──E'

說明：

  • D’、E’ 為重寫後的新 commit
  • 原本的 D、E 被替換
PR 合併回 main
main:    A──B──C──────────M
                         /
feature:            D'──E'

特性

  • feature 歷史線性化
  • main 保持穩定
  • 需要理解 rebase 原理
  • 已 push 後需：
1
git push --force-with-lease

核心差異對照

面向 策略 A（Merge） 策略 B（Rebase + Merge）
是否改寫歷史 否 是（僅 feature）
Graph 結構 交叉 主線乾淨
操作風險 低 中
適合新手 是 否
歷史可讀性 中 高

決策判斷依據

優先考量安全性與穩定性 → 使用策略 A
優先考量 commit 歷史整潔 → 使用策略 B

實務常見折衷方案

  • Feature branch → 使用 rebase
  • Main branch → 僅允許 merge commit
  • 禁止 rebase main

兼顧主線安全與歷史整潔。

原始問題（自然語言）
團隊開發
是都使用 merge 去做開發分支的更新
還是使用 rebase 去做開發分支的更新？
所產生