git merge 是将指定分支合并到当前所在分支，而非自动切换目标分支；是否成功取决于历史线性、冲突及当前HEAD位置；快进合并不产生新提交，--no-ff则强制生成含双父提交的合并记录；冲突需手动解决并 git add 标记；合并后须 git push 并用 git branch -d 安全清理本地分支。
git merge 不是“把代码复制过去”，而是让 Git 找到两个分支的共同祖先，再把差异合并成一个新提交。能不能顺利合并，取决于历史是否线性、有没有冲突、以及你当前在哪个分支上。
切换分支前先确认 HEAD 指向谁
很多人执行 git merge feature 报错或合并到错的地方，根本原因是没注意当前分支。Git 总是把指定分支合入「当前所在分支」，不是你想的“合入 main”就自动切过去。
- 用
git status看一眼最保险：输出第一行会写 “On branch main” 或类似信息 - 别依赖记忆，尤其在多人协作时，
git checkout main和git checkout -b main完全不是一回事 - 如果误在
feature分支上执行git merge main，结果就是把 main 合进 feature——这通常不是你要的流向
快进（fast-forward）和非快进（--no-ff）的区别在哪
快进合并不产生合并提交，只是移动指针；非快进强制生成一个带两个父提交的 merge commit。区别不在“能不能合”，而在“要不要留下合并痕迹”。
- 快进发生条件：
main自从分出feature后没任何新提交 → Git 直接把main指针推到feature顶端 -
git merge --no-ff feature强制生成合并提交，适合上线前合并、需要审计轨迹的场景 - 团队约定用
--no-ff是常见实践，否则看日志会丢失“这次是一次集成动作”的语义
冲突不是错误，而是 Git 在等你做决定
冲突文件里出现的 <<<<<< HEAD、=======、>>>>>> feature 不是 bug，是 Git 标记出“两边都改了同一段”的位置。删掉标记本身不会解决冲突，关键是保留哪边逻辑、怎么组合。
- 冲突只发生在「同一文件的同一块区域被两个分支各自修改」时；改不同行、不同文件不会触发
- 解决后必须用
git add <file>显式标记为已处理，否则git commit会失败并提示 “fix conflicts and run git commit” - 别跳过
git status：它会明确列出 “Unmerged paths”，比靠感觉找文件靠谱得多
合并后别忘了推送到远程和清理本地分支
本地合并成功 ≠ 团队其他人能看到。而且留着已合并的本地分支，下次 git branch 列表会越来越长，容易选错目标。
- 推送合并结果：
git push origin main（假设你合进了 main） - 安全删除本地源分支：
git branch -d feature——-d是安全删除，Git 会检查是否已完全合并，未合并则拒绝；想强制删用-D，但不推荐 - 远程分支要手动删：
git push origin --delete feature，这个动作不会自动发生
git merge 命令解决，得看上下文。 
