git merge feature合错分支最常见原因是当前在feature分支执行了合并，导致将main合入feature；必须先用git status确认当前分支，再切换到目标分支执行合并。
合并分支不是“把代码复制过去”，而是让 Git 找到两个分支的共同祖先，再把差异打包成一个新提交；能不能成功，只取决于你当前在哪个分支、有没有冲突、历史是否线性。
git merge feature 为什么合错了分支
最常见错误：你在 feature 分支上执行了 git merge main，结果是把 main 合进了 feature——这通常不是你要的流向。
- Git 总是把指定分支合入「当前所在分支」，不自动切分支
- 执行前必须确认当前分支：
git status第一行会写 “On branch main” 或类似信息 - 别依赖记忆，尤其在多人协作中，
git checkout main和git checkout -b main完全是两回事 - 误操作后可立刻用
git reset --hard HEAD~1撤回（前提是还没push）
fast-forward 和 --no-ff 的实际影响
快进（fast-forward）只是移动指针，不产生新提交；--no-ff 强制生成带双父的合并提交。区别不在“能不能合”，而在“要不要留下集成痕迹”。
- 默认 fast-forward：适合本地快速同步，日志里看不出“这是一次合并动作”
-
git merge --no-ff feature：强制生成 merge commit，适合上线前合并、审计或团队约定 - 如果想统一风格，可在项目级配置：
git config --add merge.ff false - 注意：
--no-ff不解决冲突，也不改变合并逻辑，只影响提交图谱形态
冲突文件里出现 <<<<<<、=======、>>>>>> 是正常标记
这些符号不是 bug，是 Git 在告诉你：“同一段代码，两边都改了，你得选或调和。”删掉标记本身不解决问题，关键是逻辑取舍。
- 冲突只发生在「同一文件的同一块区域被两个分支各自修改」时；改不同行、不同文件不会触发
- 解决后必须用
git add <file>显式标记为已处理，否则git commit会失败并提示 “fix conflicts and run git commit” -
git status会明确列出 “Unmerged paths”，比靠感觉找文件靠谱得多 - 三选一策略：用
git checkout --ours <file>保留当前分支版本，git checkout --theirs <file>保留被合入分支版本（注意方向！）
合并完不 push、不清理，等于没做完
本地合并成功 ≠ 团队其他人能看到；留着已合并的本地分支，下次 git branch 列表会越来越长，容易选错目标。
- 推送前建议先
git push --dry-run origin main看是否符合预期 - 推送后及时清理本地分支：
git branch -d feature（安全删除，拒绝未合并分支）或git branch -D feature（强制删除） - 远程分支需手动删除：
git push origin --delete feature - 别跳过
git log --oneline --graph --all快速核验合并后拓扑结构，一眼看出是否多出 merge commit 或意外分叉
真正容易被忽略的点是：合并前的环境干净度和合并后的拓扑验证。很多人卡在冲突里反复重试，其实问题早在 git checkout main 之前就埋下了——比如忘了 git pull origin main 导致本地落后，或者 git stash 没清完就硬切分支，后续所有操作都在一个“假干净”的基础上展开。
