跳至主要内容

Git Branch 範本

用途：Git 分支策略、PR workflow、release branching

適用場景：

  • 「我們用 git flow 還是 trunk-based」
  • 「新人看的 PR 流程」
  • 「hotfix 怎麼處理」

範本 1：簡單 feature branch​

關鍵語法：

  • commit 新增 commit
  • branch X 建分支
  • checkout X 切到分支
  • merge X 合併分支回當前
  • tag: "v1.0" 打 tag

範本 2：GitFlow 完整流程​

使用時機：團隊用 GitFlow 或複雜 release 流程。

範本 3：Trunk-based（GatherTech 風格）​

符合 GST 慣例：

  • feature/{issue-id}-{desc} 新功能
  • fix/{issue-id}-{desc} 修正
  • 直接 merge 回 main，不用 develop 中介

範本 4：Per-Phase PR（Jope.Core 風格）​

使用時機：describe per-phase PR 策略（multiple issues in single PR）。

客製化指南​

Commit ID 命名​

  • 用有意義的描述（add login form）
  • 加 Issue ID（JOP-237: setup）
  • 不要用代號（c1, c2）

Tag 使用​

  • Release tag：tag: "v1.2.0"
  • Phase tag：tag: "Phase-1"
  • Milestone：tag: "Launch"

分支命名建議（符合 GST 規則）​

feature/{lang}-{issue-id}-{description}
fix/{lang}-{issue-id}-{description}
docs/{description}
chore/{description}

何時用 gitGraph vs 其他​

情境用 gitGraph用其他
Git 分支教學✅—
Release workflow✅—
開發流程（非 git）❌flowchart
軟體架構❌flowchart
Deployment pipeline❌flowchart

Real-world 使用場景​

給新人的 Onboarding 文件​

用 gitGraph 展示：

  • PR 流程
  • 分支命名慣例
  • 何時用 feature/ fix/ docs/

Release Notes​

用 gitGraph 展示：

  • 版本之間的分支樹
  • Hotfix 時間線

Retrospective​

用 gitGraph 回顧：

  • 過去某個 sprint 的 branching
  • 找出 branching smell

Anti-patterns​

❌ Commit 沒寫描述​

commit
commit
commit

改成：

commit id: "add login form"
commit id: "add validation"
commit id: "fix bug"

❌ 分支名不清楚​

branch newthing

改成：

branch feature/gst-210-refactor-hw-inspector

❌ 沒 tag 標里程碑​

Release 卻沒打 tag：

merge feature/X

改成：

merge feature/X tag: "v1.2.0"