團隊協作必讀：ThoughtBot 標準 Git 工作流完整指南

為什麼需要規範的 Git 流程？

團隊開發中，若缺乏清晰規範，提交記錄易變得混亂難維護。ThoughtBot 的 Git 工作流被廣泛認可，核心原則：功能分支隔離、提交歷史整潔、代碼評審把關。

七步標準化流程

第一步：從最新主幹拉取功能分支

git checkout master
git pull
git checkout -b myfeature  # 新建功能分支

確保基於最新 master 開發，避免後期衝突。

第二步：規範提交變更

git add --all        # 暫存所有變更（含新增/修改/刪除）
git status           # 確認變更文件
git commit --verbose # 顯示 diff 詳情，撰寫高質量提交信息

git add . 在 Git 2.0+ 為預設行為。

第三步：撰寫優質提交信息

Present-tense summary under 50 characters

* More details (under 72 chars).
* More details (under 72 chars).

https://project.management-system.com/ticket/123

• 首行：50 字內祈使語氣摘要（如 "Add user login validation"）。
• 空行後：說明 原因、主要變更、注意事項，每行 ≤ 72 字。
• 尾行：關聯 Issue/PR 鏈接。

第四步：頻繁同步主幹

git fetch origin
git rebase origin/master

用 rebase 而非 merge，保持歷史線性乾淨，減少無謂合併提交。

第五步：合併提交—— 互動式 Rebase

功能完成後，將多個碎碎提交壓縮為 1-3 個邏輯提交：

git rebase -i origin/master

進入互動介面，將需合併的提交前綴改為 s (squash) 或 f (fixup)：

pick 07c5abd Introduce OpenPGP
s de9b1eb Fix PostChecker::Post#urls
s 3e7ee36 Stop highlighting
pick fa20af3 Interactive rebase guide

• squash：合併並保留提交信息；fixup：合併但丟棄該提交信息。
• 亦可用 git commit --fixup <commit> + git rebase -i --autosquash 自動化。

第六步：強制推送遠端功能分支

git push --force origin myfeature

--force 必須加：rebase 重寫歷史，遠端分支需強制覆蓋。

第七步：發起 Pull Request 接受 Code Review

推送後發起 PR 到 master，邀請團隊審查，通過後合併入主幹。

核心價值總結

• 原子性提交： 每個提交代表完整邏輯單元，便於回滾與審查。
• 線性歷史： Rebase 避免「合併氣泡」，歷史圖清晰可讀。
• 可追溯性： 提交信息關聯工單，上下文完整。

堅持此流程，團隊協作效率與代碼質量將顯著提升。