功能分支写完，切回 main 执行 git merge feature/login，终端蹦出 CONFLICT，提示 Merge conflict in src/app.js。这不是命令写错，是两条分支改了同一块代码。

git合并分支的本质是把另一条分支的提交并进当前分支，当前在哪个分支很关键。很多人站在 feature 上执行 merge main，方向正好反了，历史也会乱。

标准合并就四步

git checkout main; git pull; git merge feature/login; git push

合并前先 pull，把远程 main 的新提交拉下来，能少一次推送被拒。合并完先本地跑一遍测试，再 push，别把冲突没清干净的代码推上去。

冲突文件怎么改

git status 会列出 both modified 的文件。打开文件能看到三块内容：当前分支的版本、分隔线、另一条分支的版本。保留需要的部分，把标记行删掉，再 git add 和 git commit。

git status; git add src/app.js; git commit -m 'merge feature/login'

改一半发现搞不定，直接 git merge --abort 回到合并前，比硬着头皮改安全。已经提交了想撤销，用 git reset --hard 要谨慎，会丢工作区改动，先确认没有未保存的东西。

fast-forward 和 --no-ff

两条分支没有分叉时，Git 默认直接移动指针，叫 fast-forward，历史是一条直线。加 --no-ff 会强制生成一个合并提交，能看出功能分支的边界。团队要查这个功能什么时候合的，用 --no-ff 更清楚；提交本来就少，直线也无所谓。

合并前先对齐主干

分支开了一两周，main 已经跑远，先在 feature 上 merge main 或 rebase main，把冲突解决在小分支里。主干保护分支别直接 push，走合并请求，出了问题好回滚。git合并分支没有绝对好坏，团队统一一种，别今天 merge 明天 rebase。