從個人到團隊、再到帶人：我實際在用的 Git 工作流

Git 的指令學起來不難，難的是「一群人怎麼一起用它而不互相打架」。我從一個人寫專案、到團隊協作、到後來帶人要為流程把關，對 Git 工作流的看法也一直在變。這篇講的不是指令教學，是我實際在不同階段採用的策略，以及為什麼。

一個人的時候：簡單但留紀錄

自己一個人寫，不需要複雜流程，但我還是堅持兩件事：commit 訊息寫清楚、功能分支開來做。

commit 訊息我會寫「為什麼這樣改」，而不只是「改了什麼」——因為三個月後回來看的那個人就是我自己，而我什麼都不記得了。功能分支則讓我能同時放著好幾條沒做完的線，不會把半成品混進主線。

團隊協作：分支策略要配合節奏

到了團隊，重點變成「怎麼讓多人平行開發又能穩定發布」。流派很多，但我的選擇邏輯是看團隊的發布節奏：

• 如果是持續部署、每天上很多次：我偏好簡單的主幹開發配短命的功能分支——從 main 開分支、快速做完、合回 main 馬上部署。分支活得越短，合併衝突越少
• 如果有明確的版本、需要同時維護多個發布：才需要比較重的分支模型（區分開發線與發布線）

我看過太多小團隊硬套很重的分支模型，結果光是搞懂「這個東西該合到哪條分支」就耗掉一堆精力。流程要配合團隊，不是團隊去配合流程。

Pull Request 是溝通，不只是合併

PR 對我來說最大的價值不是「合併程式碼」這個動作，而是它創造了一個討論的場合。一個好的 PR：範圍小、講清楚改了什麼和為什麼、容易被 review。

我帶人時很強調 PR 不要做太大。一個改了 50 個檔案的 PR，沒人能認真 review，最後就是橡皮圖章蓋過去——那 review 就失去意義了。寧可拆成幾個小 PR，每個都能被好好看過。

commit 歷史是寫給未來的人看的

我傾向讓主線的歷史保持乾淨、可讀。功能分支上的雜亂 commit（「修一下」「再修一下」）在合併前可以整理。一段清楚的歷史，在你需要追「這個 bug 是哪個改動引入的」時，價值會突然變得很高。

但這要拿捏：已經推出去、別人可能基於它工作的歷史，我不會去改寫，那只會製造混亂。改寫只發生在還沒分享出去的本地分支。

帶人之後的體會：流程是為了降低恐懼

當我要為團隊的流程負責時，我的思考從「怎樣最有效率」變成「怎樣讓每個人都能安心地交付」。一個好的 Git 流程應該讓最資淺的成員也敢按下合併鍵——因為有分支保護、有 CI 自動跑測試、有 review 把關，就算出錯也擋得住、回得來。

流程的目的不是限制人，是降低每一次改動的恐懼。當大家不再害怕弄壞主線，整個團隊的速度反而會變快。

小結

我在不同階段的 Git 心得：

• 一個人：分支隔離、commit 訊息寫「為什麼」
• 團隊：分支策略配合發布節奏，別過度設計
• PR 要小、是溝通的場合而非橡皮圖章
• 主線歷史保持乾淨可讀，但別改寫已分享的歷史
• 帶人時，流程的目標是降低恐懼、讓人敢交付

工具是死的，協作是活的。Git 工作流真正在處理的，其實是「人怎麼一起工作」這件事。