在團隊協作中，Git分支合併是日常操作，但每次合併遇到“衝突”（Conflict）都會讓人頭大——不僅浪費時間，還可能破壞代碼邏輯。今天分享5個實用技巧，幫你從根源減少衝突，讓分支合併更順暢。

技巧一：明確分支職責，避免“一鍋亂燉”¶

核心：不同分支只負責一件事，讓合併範圍清晰。
常見分支類型：
- main（或master）：只放穩定可發佈的代碼，禁止直接修改。
- feature/*：功能分支（如feature/user-login），專門開發新功能。
- bugfix/*：修復分支（如bugfix/login-error），只處理線上bug。
- release/*：發佈分支（如release/v1.0），準備版本發佈時用。

操作示例：
如果你在開發“用戶登錄”功能，就用feature/login分支；修復“購物車bug”，用bugfix/cart-count分支。每個分支職責明確，合併時就知道該從哪合到哪，避免誤合併。

技巧二：小步提交，讓合併“輕裝上陣”¶

核心：每次提交只做“最小改動”，減少單次合併的代碼差異。
原理：如果一次合併改了100行代碼，衝突概率比改10行大得多。

操作示例：
寫代碼時，按“小任務”拆分提交：
- 先寫“登錄表單輸入框”（git commit -m "Add username input"）
- 再寫“密碼輸入框”（git commit -m "Add password input"）
- 最後寫“表單驗證邏輯”（git commit -m "Validate login inputs"）

每個小改動合併到主分支時，衝突會少很多，甚至直接“自動解決”。

技巧三：頻繁同步主分支，別讓分支“脫節”¶

核心：每天花5分鐘，把主分支最新代碼拉到你的功能分支，保持“同步更新”。

錯誤案例：
如果你兩週沒碰主分支，主分支已改了你的功能分支裏的同一文件，合併時衝突會爆炸。

正確操作：

# 1. 切換到主分支，拉取最新代碼
git checkout main
git pull origin main  

# 2. 切回你的功能分支，合併主分支最新代碼
git checkout feature/login
git merge main  

# 如果衝突少，直接解決；衝突多的話，用rebase（見技巧四）

建議：每天固定時間做一次同步（比如早會或下班前），養成“不脫節”的習慣。

技巧四：用rebase整理提交，讓歷史更“乾淨”¶

核心：rebase能把你的提交“移植”到主分支最新代碼後，減少合併時的“分叉歷史”，降低衝突。

適用場景：
- 自己的本地分支（未推到遠程）：比如你開發feature/pay時，主分支已更新。
- 想讓提交歷史更“線性”（類似“把所有樹枝變直”）。

操作示例：

# 在功能分支上執行rebase，把主分支最新代碼“接”到你的提交後面
git checkout feature/pay
git rebase main  

# 如果遇到衝突，解決後執行：
git add 衝突文件
git rebase --continue  

# 完成後，你的提交歷史會變成“主分支最新代碼 → 你的所有提交”，乾淨無分叉

注意：rebase會改變提交歷史，禁止在已推到遠程的分支使用（會導致團隊其他人的提交混亂）。

技巧五：衝突不可怕，“看懂標記”就能解決¶

核心：衝突是Git在告訴你“這裏有多人修改，需要人工確認”，看懂標記就能解決。

衝突標記含義：

<<<<<<< HEAD (當前分支的代碼)
原來的代碼：用戶名輸入框
=======
要合併的代碼：用戶賬號輸入框
>>>>>>> feature/new-username (要合併的分支)

解決步驟：
1. 打開衝突文件，找到<<<<<<<、=======、>>>>>>>標記。
2. 根據業務邏輯修改代碼（比如確認“用戶賬號”是否正確）。
3. 刪除衝突標記，保留最終代碼（如用戶賬號輸入框）。
4. 執行git add 文件名標記爲已解決，再繼續合併/提交。

小技巧：不確定時，直接問修改該部分的同事，避免改亂邏輯。

總結¶

減少Git分支合併衝突的關鍵是：明確分支職責、小步提交、頻繁同步、保持歷史乾淨、正確解決衝突。剛開始可能需要適應，但堅持這些習慣後，你會發現“衝突”從“噩夢”變成“小插曲”。記住：Git是工具，合理使用才能讓協作更高效！