前言

Git 已成為現代軟體開發不可或缺的版本控制工具。然而，許多團隊在使用 Git 時仍面臨各種挑戰：分支管理混亂、提交訊息不清、合併衝突頻繁等問題。本文將分享 Git 工作流程的最佳實踐，涵蓋分支策略選擇、提交訊息規範、Pull Request 流程以及 Code Review 要點，幫助你的團隊建立更順暢的協作模式。

分支策略：選擇適合團隊的模型

Git Flow

適合有明確版本發布週期的專案。主要分支包括：

  • main：生產環境程式碼，永遠保持穩定
  • develop：開發主分支，整合各功能分支
  • feature/*：功能開發分支
  • release/*：發布準備分支
  • hotfix/*：緊急修補分支

GitHub Flow

更簡潔的模型，適合持續部署的專案：

  • main：永遠可部署
  • 從 main 開啟功能分支
  • 完成後透過 Pull Request 合併回 main

Trunk-Based Development

適合成熟團隊與 CI/CD 完善的專案：

  • 開發者直接在 main/trunk 上開發
  • 使用 feature toggle 控制功能開關
  • 強調小批量、頻繁整合

提交訊息規範

良好的提交訊息是專案可維護性的關鍵。建議採用 Conventional Commits 規範：

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

<body>

<footer>

常見的 Type

Type 說明
feat 新功能
fix 錯誤修復
docs 文件更新
style 程式碼格式調整
refactor 重構
test 測試相關
chore 建置、工具相關

實際範例

feat(auth): 新增 OAuth 2.0 登入功能

- 支援 Google、GitHub 第三方登入
- 新增 token 刷新機制
- 實作登入狀態持久化

Closes #123

Pull Request 最佳實踐

建立 PR 前

  1. 確保程式碼可運作：在本機充分測試
  2. 保持 PR 範圍小：一個 PR 只做一件事
  3. 自我審查：提交前先檢視自己的變更
  4. 撰寫清楚的 PR 描述：說明目的、變更內容、測試方式

Code Review 要點

  • 及時審查：盡量在 24 小時內完成
  • 建設性回饋：指出問題並提供建議
  • 關注重點：邏輯正確性 > 程式碼風格
  • 使用同意用語：必要時使用 conventional comments（如 nit:、question:、issue:）

常見問題與解決方案

合併衝突處理

當發生衝突時：

  1. 先執行 git fetch origin 取得最新狀態
  2. 使用 git rebase origin/main 將分支更新到最新
  3. 手動解決衝突後執行 git rebase --continue
  4. 完成後強制推送 git push --force-with-lease

避免的壞習慣

  • ❌ 直接在 main 分支開發
  • ❌ 提交大量無關的變更
  • ❌ 使用模糊的提交訊息（如「fix bug」、「update」）
  • ❌ 忽略 CI/CD 失敗就合併

工具推薦

提交規範工具

  • commitlint：檢查提交訊息格式
  • husky：設定 Git hooks
  • commitizen：互動式提交訊息產生器

Code Review 工具

  • GitHub/GitLab Pull Requests：內建的審查功能
  • Reviewable：更強大的 GitHub PR 審查工具
  • Danger：自動化 PR 審查規則

結語

良好的 Git 工作流程需要團隊共同建立並遵守。建議從以下步驟開始：

  1. 選擇適合團隊的分支策略
  2. 導入提交訊息規範並自動化檢查
  3. 建立 Code Review 文化與流程
  4. 持續優化並根據團隊需求調整

記住，沒有「最好的」工作流程，只有「最適合」你團隊的工作流程。從簡單開始，逐步優化，才能建立真正高效的協作模式。

你覺得你的團隊目前使用的工作流程有哪些可以改進的地方？歡迎在下方留言分享你的經驗！