预计阅读时间：3 分钟
Feature 分支开发完成后，最终要合并回 main。
最简单的情况是这样的：
main: A -> B
feature: -> C -> D
如果 main 在这期间没有新提交，合并通常很顺利：
git merge feature/login
Git 可能直接做一次 Fast Forward，也就是快进合并。
但现实里很少这么安静。
你开发登录功能时，别人可能已经往 main 合并了新代码：
main: A -> B -> E
feature: -> C -> D
这时再合并，Git 就需要判断两边代码怎么放到一起。
如果两边改的是不同文件，通常没问题。
如果两边改了同一行，或者逻辑互相影响，就可能出现冲突。
Git 会提示：
CONFLICT
很多人第一次看到冲突会慌，其实没必要。
冲突文件里通常会出现这样的标记：
<<<<<<< HEAD
const timeout = 3000
=======
const timeout = 5000
>>>>>>> feature/login
它的意思是：
HEAD：当前分支里的代码feature/login：要合并进来的代码
你要做的事不是猜 Git 想干什么，而是自己判断：到底保留哪一版，或者重新写一版。
解决后执行：
git add .
git commit
冲突就处理完了。
想减少冲突，可以养成几个习惯：
- 开发前先
git pull origin main - 分支不要拖太久才合并
- 一个分支只做一个功能
- 提交前先看
git status - 合并前认真看 diff
分支命名也很重要。
推荐：
feature/login
feature/payment
fix/order-timeout
hotfix/api-crash
不要用：
test
aaa
new
最终版
真的最终版
后者短期省事，长期一定痛苦。
功能上线后，可以删除本地分支：
git branch -d feature/login
想查看分支结构，可以用：
git log --graph --oneline --all
这条命令非常适合新手理解 Git 分支到底是怎么走的。
3 个关键点：
- 冲突不是灾难，只是两边代码需要人工判断。
- 小分支、短周期、勤同步，可以减少冲突。
- 分支命名要清晰，方便团队协作和后期维护。
本文由 楸木 原创，转载请注明出处。