在多人協作開發中，Git的分支管理就像一條看不見的“交通規則”，讓每個人的代碼變更有序進行，避免混亂。如果沒有規範的分支策略，團隊成員可能會在同一個文件上互相修改，導致代碼衝突、功能混亂甚至部署失敗。這篇文章會用最簡單的方式，讓你理解爲什麼需要分支管理，以及如何在團隊中規範使用Git。

爲什麼需要分支管理？¶

想象一下：你和同事同時在寫一個項目，你改了login.js，同事也改了login.js，如果直接提交到主分支，就會出現代碼衝突——系統不知道該保留誰的修改。更糟糕的是，如果你們都把代碼直接推到主分支，主分支的代碼可能隨時被破壞，導致項目無法運行。

分支管理的核心作用是：讓每個人在獨立的“線路”上開發，互不干擾，最後再合併成果。就像一條主路（主分支）分成多條支路（功能分支），大家在各自的支路上修路，最後再把支路和主路連接。

Git分支基礎：從“一條線”到“多線路”¶

什麼是分支？¶

分支（Branch）本質上是代碼的不同版本線。默認情況下，Git只有一條主分支，通常叫master或main（現在很多項目用main）。當你創建一個新分支時，相當於複製了當前的代碼狀態，你可以在這個新分支上自由修改，而不會影響主分支。

常用分支類型¶

• 主分支（main/master）：永遠保持可部署的穩定代碼，只接受合併，不直接提交代碼。
• 功能分支（feature/*）：用來開發新功能，比如feature/user-center（用戶中心功能）。
• 修復分支（bugfix/*）：用來修復線上問題或開發中的小bug，比如bugfix/login-error。
• 臨時分支（hotfix/*）：緊急修復生產環境的bug（如服務器崩潰），需要優先合併到主分支。

最適合初學者的分支策略：簡化版GitHub Flow¶

複雜的策略（如Git Flow）對新手來說門檻太高，這裏推薦最簡單的GitHub Flow，核心思想是：主分支永遠可部署，所有功能通過“創建分支→開發→合併PR”完成。

1. 主分支（main）：永遠“乾淨可用”¶

• 只有合併後的代碼才能推到main，且main代碼必須能直接運行。
• 禁止直接在main分支上提交代碼（除非緊急修復）。

2. 功能分支（feature/*）：獨立開發¶

• 創建分支：從main分支拉取最新代碼，創建新功能分支。

  git checkout main  # 先確保在主分支
  git pull origin main  # 拉取最新主分支代碼
  git checkout -b feature/user-center  # 創建並切換到功能分支

• 開發功能：在分支上寫代碼，定期提交。

  # 修改文件後
  git add .  # 添加所有修改
  git commit -m "feat: 完成用戶中心頁面佈局"  # 提交信息規範見下文

• 推送分支：把功能分支推到遠程倉庫，方便團隊協作。

  git push -u origin feature/user-center  # -u記住遠程分支，後續可直接git push

3. 合併代碼：通過PR/MR完成“代碼審查”¶

• 在GitHub、GitLab等平臺上，功能分支推到遠程後，發起Pull Request（PR） 或 Merge Request（MR）。
• 團隊成員會審查代碼（檢查邏輯、風格、是否有bug），通過後合併到main分支。
• 合併後：刪除功能分支（本地和遠程都刪，避免混亂）。

團隊協作規範：讓所有人“心照不宣”的約定¶

1. 分支命名規則（清晰易懂）¶

• 功能分支：feature/功能描述（如feature/wechat-login）
• 修復分支：bugfix/問題描述（如bugfix/login-crash）
• 主分支：main（固定，不要改）
• 緊急修復：hotfix/生產bug（如hotfix/payment-error）

2. 提交信息規範（讓別人秒懂改了啥）¶

提交信息要清晰，方便後續查日誌或回滾。推薦約定式提交（Conventional Commits），格式：

<類型>[可選作用域]: <描述>
[可選正文]
[可選腳註]

• 類型：feat（新功能）、fix（修復bug）、docs（文檔）、refactor（重構）、test（測試）。
• 示例：
• feat: 添加用戶註冊表單（新功能）
• fix: 修復移動端按鈕點擊無響應（修復bug）
• docs: 更新API文檔說明（文檔修改）

3. 開發流程：禁止“野路子”¶

• 禁止直接push到主分支：永遠通過功能分支開發，再合併到主分支。
• 禁止頻繁提交“大雜燴”：每次提交聚焦一個小功能或修復，方便代碼審查和回滾。
• 定期同步主分支代碼：開發中如果主分支有更新，及時拉取合併，避免後期衝突過大。

  git checkout feature/user-center
  git pull origin main  # 拉取主分支最新代碼，合併衝突後再繼續開發

4. 代碼審查：避免“低級錯誤”¶

• 代碼審查是團隊協作的關鍵，能發現邏輯漏洞、安全問題，還能傳遞經驗。
• 審查時關注：代碼邏輯是否正確、是否符合項目規範、是否有重複代碼。

常見問題與解決方法¶

1. 分支衝突怎麼辦？¶

如果多人同時修改了同一個文件，合併時會出現衝突。解決步驟：
1. 拉取主分支最新代碼：git pull origin main
2. Git會提示衝突文件（如<<<<<<< HEAD標記你的修改，=======後是別人的修改）
3. 手動編輯衝突文件，刪除<<<<<<<、=======、>>>>>>>，保留正確內容
4. 保存後提交：git add . + git commit -m "merge: 解決衝突"

2. 提交信息寫錯了怎麼改？¶

如果還沒推送到遠程，直接修改提交信息：

git commit --amend -m "fix: 修正用戶頭像上傳bug"

3. 分支太多太亂，怎麼清理？¶

合併到主分支後，遠程功能分支可以刪除（在平臺上點“Delete branch”）；本地不需要的分支也可以刪除：

git checkout main
git pull origin main
git branch -d feature/old-feature  # 刪除本地分支

總結¶

Git分支管理的核心是“規範”與“協作”：通過分支隔離開發，通過規範減少溝通成本，通過協作提升代碼質量。對初學者來說，不必一開始追求複雜策略，先掌握簡化版GitHub Flow，養成“功能分支開發→PR合併→及時清理”的習慣，就能避免團隊協作中的大部分混亂。

記住：好的分支策略，能讓團隊像流水線一樣高效協作，讓每個開發者都能專注於自己的任務，而不是擔心代碼衝突或版本混亂。從今天開始，試試用規範的分支管理吧！