工作一年多的經驗總結，Git 分支管理實戰指南：創建、合併與衝突解決（建議收藏）！
整理版優先睇
Git分支管理實戰：隔離風險、有序合併、從容撤銷
佢係一個開發咗一年多嘅後端開發者，身處小團隊，以前圖方便直接喺 master 提交 code。結果有次領導要睇最新系統功能，佢啱啱改完 code 未測試，冇辦法及時發佈，搞到好尷尬。為咗避免呢種情況再發生，佢強制自己用分支開發，並將工作中最常遇見嘅場景同處理方法整理出嚟，特別適合團隊人數少、或者一個人維護幾個項目嘅開發者參考。
呢篇文章嘅核心觀點係：分支最主要嘅目的係隔離風險，將唔穩定嘅 code 鎖喺獨立分支入面測試，master 永遠保持可發佈狀態。作者按三種常見場景介紹分支使用：開發新功能用 feature 分支、緊急修復線上 bug 用 hotfix 分支、發佈前穩定版本用 release 分支。佢強調命名規範嘅重要性，用前綴分類同短橫線命名，令到分支一目瞭然。合併方面建議小團隊用 merge 就足夠，唔好一開始就追 rebase。
對於合併衝突，佢提出最常見嘅衝突係自己唔同分支之間嘅衝突，因為自己寫嘅 code 反而容易解決。解決衝突最直接嘅方法係用 IDE 一鍵處理，唔使手動刪標記。而如果合併錯咗，就根據推唔推送決定用 reset 定 revert，並畀出三種情況嘅具體指令。總括來講，養成習慣用分支開發，可以避免好多突發尷尬，令開發流程更順暢。
- 結論：分支嘅核心係隔離風險，master 保持可發佈狀態。
- 方法：按場景用 feature、hotfix、release 分支，命名用前綴加短橫線。
- 差異：小團隊用 merge 就夠，rebase 可以等熟練先學。
- 啟發：合併衝突通常係自己分支之間嘅衝突，用 IDE 解決最快。
- 可行動點：合併錯咗，未 push 用 reset，已 push 用 revert。
分支命名規範原則
用前綴分類（feature/hotfix/release）加描述，用短橫線分隔，命名明確用途。
分支撤銷操作流程
一、未處理完衝突後悔：git merge --abort；二、合併完成未推送：git reset --hard HEAD~1；三、已推送：git revert -m 1。注意：已推送唔好用 reset。
分支隔離風險：由尷尬到從容
作者以前直接喺 master 提交 code，結果領導突擊檢查時冇辦法演示最新功能。呢次尷尬令佢意識到分支嘅核心價值——隔離風險。
隔離風險
將唔穩定嘅 code 鎖喺獨立分支入面測試，master 永遠保持可發佈狀態。咁樣領導幾時睇都得。
master 永遠保持可發佈狀態
- 1 開發新功能 → feature 分支：任何新功能都從 master 拉 feature 分支，寫完測試無誤先合返 master。
- 2 緊急修復線上 Bug → hotfix 分支：從 master 拉 hotfix 分支，修完直接合返 master 發佈，唔影響其他改動。
- 3 準備版本發佈 → release 分支：功能凍結後拉 release 分支，只修 bug 唔加新功能，穩定後合到 master 並打 tag。
分支創建與操作：命令同命名規範
作者整理咗幾個最常用嘅分支操作命令，同埋命名規範嘅三個原則。
命令速查
- 創建並切換分支：git checkout -b <branch-name> 或 git switch -c <branch-name>
- 查看所有分支：git branch -a
- 查看分支圖：git log --oneline --graph --all
- 刪除已合併分支：git branch -d <branch-name>
- 強制刪除分支：git branch -D <branch-name>
命名規範有三個原則，作者認為前綴帶嚟嘅清晰度係零成本。
前綴帶嚟嘅清晰度係零成本
- 1 用 / 分隔類型同名稱：例如 feature/user-login、hotfix/payment-null-pointer、release/v1.2.0，一看就知分支用途。
- 2 用短橫線，唔用下劃線：避免工具（如 Jira）將下劃線轉空格搞到連結斷開。
- 3 命名要明確用途：例如 fix-payment-null-pointer 比 fix-bug 更清楚，一個月後都知係修邊個 bug。
合併與衝突：小團隊用 merge 就夠
合併分支有兩個主流方式：merge 同 rebase。作者建議小團隊用 merge 就夠，rebase 等以後分支多咗、歷史亂咗再學都未遲。
用 merge 就夠
git merge 會產生一個新嘅 merge commit，保留完整歷史，好處係操作簡單、一目瞭然。缺點係分支一多，提交歷史會有分叉線。
保留完整歷史
衝突嘅本質係你改咗某一行，另一個分支都改咗同一行，Git 唔知聽邊個。小團隊最常見嘅衝突係自己唔同分支之間嘅衝突，反而容易解決。
衝突嘅本質係你改咗，佢又改咗
解決衝突步驟：先用 git status 揾到 both modified 嘅檔案，打開檔案解決衝突標記（<<<<<<< HEAD 到 >>>>>>>），然後 git add 同 git commit。實際開發時直接用 IDE 一鍵處理，快好多。
用 IDE 一鍵處理
合併錯咗點撤銷？三條退路
合併錯咗唔好慌，作者按情況提供三條退路。
三條退路
- 未處理完衝突就後悔：git merge --abort 即刻還原到合併前狀態。
- 合併完成但未推送：git reset --hard HEAD~1 回退一個 commit，注意會丟棄未提交改動。
- 已經推送畀其他人：用 git revert -m 1 HEAD 生成一個新 commit 反向撤銷，唔破壞歷史。
另外，如果 hotfix 修復咗 master，記得用 cherry-pick 或者直接 merge 將修復同步到 develop 分支。
cherry-pick
寫在開頭
hi，我是kele。
我們公司開發人員不多，為了圖方便，我們的開發人員在大多數情況下的git push都提交在 master ，這其實沒有什麼大問題。久而久之就發現，有時候領導突然要看最新的系統功能，而我剛好改了代碼、沒有測試、沒有辦法及時發佈。所以為了避免日後尷尬，我強制自己用分支開發。
我把工作一年多經常遇到的場景以及處理方法做一個分享。如果你也處在一個小團隊，或者一個人維護着幾個項目，這篇應該能幫你少踩一些坑。
一、什麼時候該創建分支？
分支解決的核心問題就一個：隔離風險。
把不穩定的代碼關在獨立分支裏折騰，master 永遠保持可發佈狀態。領導什麼時候看，你什麼時候就能演示。
具體什麼場景需要分支？
場景 1：開發新功能 → feature 分支
你準備開始寫一個新功能了，不管多小，從 master 拉一個 feature 分支出來。
git checkout master
git checkout -b feature/user-login
寫完、測完、確認沒毛病了，再合回 master。功能寫一半時，你隨時可以切回 master 給領導演示，互不干擾。
哪怕是隻有你一個人的項目，這個習慣也能救命——你永遠不知道什麼時候被打斷。
場景 2：緊急修復線上 Bug → hotfix 分支
線上出了一個緊急 bug，從 master 拉 hotfix 分支，修完直接合並回 master 發佈。
git checkout master
git checkout -b hotfix/login-crash
一個命令，幾行修復，合回去就發佈。整個過程 master 上的其他改動不受影響。
注意：如果你同時還有一個 develop 分支在開發中，master 上的 bug 在 develop 上大概率也存在。修完 master 後別忘了一併修復 develop——直接把 hotfix 分支合併到 develop：
git checkout develop
git merge hotfix/login-crash
如果 develop 上改動太大不方便直接 merge，也可以用 cherry-pick 把修復的那個 commit 單獨摘過去：
git checkout develop
git cherry-pick <hotfix-上修復-bug-的-commit-hash>
場景 3：準備版本發佈 → release 分支
功能凍結了，從開發主幹拉一個 release 分支，這個階段只修 bug 不動新功能，穩定後合到 master 並打 tag。
git checkout develop
git checkout -b release/v1.2.0
小團隊可能不常用 release 分支，但如果你有"下週五必須上線"的節點，它就是個閘門，幫你鎖住版本範圍。
別怕建分支，怕的是改崩了回不去。
二、分支怎麼創建和操作？
幾分鐘速覽，備忘性質的。你是有基礎的人，這裏只撿幾個最常用、也最容易搞混的列出來。
基本命令
git checkout -b feature/api-refactor | |
git switch -c feature/api-refactor | |
git branch -a | |
git log --oneline --graph --all | |
git branch -d feature/old-login | |
git branch -D feature/old-login |
命名規範，三個原則
1. 用 / 分隔類型和名稱
feature/user-login
hotfix/payment-null-pointer
release/v1.2.0
前綴一眼就能看出這個分支是幹什麼的。你不需要整套 Git Flow，但前綴帶來的清晰度是零成本的。
2. 用短橫線，不用下劃線
feature/user-login (推薦)
feature/user_login
有些工具（比如 Jira）會把下劃線自動轉成空格，連結斷掉。不是大問題但能避就避。
3. 命名一看就知道幹什麼
fix-payment-null-pointer (推薦)
fix-bug
一個月後你翻到 fix-bug 這個分支，你能想起來是修哪個 bug 嗎？命名是寫給未來的自己看的。
三、合併分支的正確姿勢
合分支有兩個主流方式：merge 和 rebase。
對小團隊來說，merge 就夠用了。rebase 留着以後分支多了、歷史亂了再學不遲。
git merge
把目標分支的改動合併到當前分支，產生一個新的 merge commit。
git checkout master
git merge feature/user-login
優點：操作簡單，保留完整歷史，什麼時候合了誰的一目瞭然。 缺點：分支一多，提交歷史會有分叉線。
四、合併衝突了怎麼辦？
衝突的本質很簡單：你改了某個文件的某一行，另一個分支也改了同一行，Git 不知道該聽誰的。
小團隊最常見的衝突其實是你自己不同分支之間的衝突，反而好解決——因為都是自己寫的。
第一步：找到衝突文件
git status
狀態是 both modified 的文件就是衝突文件。
第二步：打開文件，解決衝突標記
<<<<<<< HEAD
const maxRetry = 3;
=======
const maxRetry = 5;
>>>>>>> feature/retry-logic
<<<<<<< HEAD到=======之間：你當前分支的內容=======到>>>>>>>之間：要合入的分支的內容
第三步：標記已解決並提交
git add .
git commit -m "merge: 解決 retry 配置衝突"
大功告成。
上面的合併步驟瞭解即可，開發的時候直接用 IDE。 VSCode 和 JetBrains 全家桶都有一鍵按鈕，點一下就行，比手動刪標記快十倍。
五、分支合併錯了如何撤銷
合併錯了，第一反應別慌，也別硬着頭皮在錯誤的合併結果上繼續改。你有三條退路，看情況選。
情況 1：正在合併中，衝突還沒處理完
後悔了，不想合了——
git merge --abort
立刻回到 merge 之前的狀態，乾乾淨淨。
情況 2：合併已完成，但還沒推送到遠程
commit 已經生成了，但只有你本地看得到——
git reset --hard HEAD~1
這條命令會把 HEAD 回退一個 commit，也就是撤銷最近一次合併，工作區也一起還原。注意 --hard 會丟棄所有未提交的改動，用之前確認沒有需要保留的東西。
情況 3：已經推送到遠程，別人可能已經 pull 了
這時候不能 reset 了——你回退了，別人的倉庫就跟你對不上。正確做法是用 revert，生成一個新的 commit 來"反向撤銷"那次合併：
git revert -m 1 HEAD
-m 1 的意思是保留主分支（被合入的那一側）的改動，撤銷被合併的分支的改動。這會在不破壞歷史的前提下安全撤銷。
簡單記：沒 push 就用 reset，已經 push 了就用 revert。動了別人也能看到的歷史，就老老實實走 revert。
寫在最後
今天就分享這麼多。
如果對你有用，轉發給你團隊裏那個也一直往 master 上懟的同事。
我們下期再見~