還在用自己名字當 Git 分支？試試看 Git Flow 吧！完整入門教學與實例分享
用自己名字當 Git branch？我真的是活教材
那天錄 Podcast 的時候，突然回憶起一段黑歷史：
原來「用自己名字當 Git 分支名稱」是個不太好的做法 😱
事情發生在我剛進公司的第一個月，身為一個對 Git 還很陌生的新手工程師，我滿心疑問地問主管：
「branch 名稱要怎麼取？」
「就用你的名字命名就好啊」
我也沒想太多，就開了個 lingling branch，接著 lingling_fix、lingling_update、lingling_dev……
如果那時候有資安部門來掃 repo，可能會以為整個專案都是我的個人 side project 🤡
還好後來我們團隊導入了 Git Flow，才沒有讓災情擴大。
為什麼不能用自己名字當 Git 分支？
雖然一開始聽起來很直覺，但實際上，這種命名方式會帶來不少問題：
- 看不出來功能內容
lingling完全無法告訴團隊這個 branch 在修什麼、做什麼功能，讓人一頭霧水。
你只能依靠 git commit 訊息，或是實際點進去看程式碼，才能搞清楚這個 branch 到底在做什麼。 - 多人協作超混亂
想像一下大家都用自己的名字開 branch，整個 repo 就像員工通訊錄一樣亂七八糟。 - 無法 trace 歷史紀錄
要回頭找出某個功能的開發歷程？祝你好運！
這時候，「有系統的分支命名規則」就非常重要，也正是 Git Flow 存在的價值。
什麼是 Git Flow？從命名開始，讓協作更有系統！
Git Flow 是一套「分支管理策略」，讓多人協作的流程變得有邏輯、好追蹤。
Git Flow 的常見分支結構：
| 分支名稱 | 用途 | 命名範例 |
|---|---|---|
main（或 master） | 上線中的正式版本 | main / master |
develop | 日常開發版本整合處 | develop |
feature/xxx | 新功能開發 | feature/login-api |
bugfix/xxx | 修復一般 bug | bugfix/fix-header-overlap |
hotfix/xxx | 緊急修 production bug | hotfix/crash-on-launch |
release/xxx | 準備發版階段用 | release/v1.2.0 |
refactor/xxx | 程式碼重構（非功能、不修 bug） | refactor/optimize-query |
比起 lingling_dev，這樣一眼就知道每個 branch 的目的與狀態。
Git Flow 基本使用流程（快速入門）
1. 從 develop 切出 feature 分支
Bash
git checkout develop
git checkout -b feature/login2. 開發完功能後合併回 develop
Bash
git add .
git commit -m "add feature: login"
git checkout develop
git merge feature/login3. 準備發版就從 develop 切出 release 分支
Bash
git checkout -b release/v1.2.04. 發版後合併到 main 並打 tag
Bash
git checkout main
git merge release/v1.2.0
git tag v1.2.05. 回補 hotfix 時也有專屬分支
Bash
git checkout main
git checkout -b hotfix/fix-crash這一套流程雖然一開始看起來比較繁瑣，但只要團隊建立默契，整體協作效率會提升超多。
常見 Git Flow 問題一次解答
Q：小團隊適合用 Git Flow 嗎？
A：非常適合！Git Flow 不需要多人也能運作，甚至一個人開 side project，也能保持版本清晰。
Q：我不想開這麼多分支，可以只用 main 和 feature 嗎？
A：可以，但要有清楚的命名規範，否則長期下來會混亂。Git Flow 的精神就是讓分支「有職責、有結構」。
Q：我現在可以直接套用 Git Flow 嗎？需要什麼工具？
A：完全可以。你只需要熟悉基本 Git 指令，不一定要額外工具。如果你想更自動化，也可以搭配 Sourcetree、GitKraken 等 GUI 工具。
我終於理解為什麼大家都在推 Git Flow
雖然一開始照著主管建議用自己名字命名分支真的滿有存在感，但那種快感只維持三天。第四天開始你就會在 commit log 裡迷失，然後開啟 lingling_dev_Q1 (fix-conflict) 開始懷疑人生 😮💨
導入 Git Flow 之後，我終於可以：
- 清楚知道自己和同事分支的用途
- 不怕 code review 時找不到來源
- 把 merge conflict 降到最低
- 更有效率地準備版本發佈
總之，不要讓分支變成「命名地獄」，給未來的自己一點善意，也給團隊一點秩序。
