git merge 应在目标接收分支上执行：要把 feature/login 合入 main，需先 checkout main 再 merge；同步 main 修复到 dev 则先 checkout dev 再 merge。
Git merge 不是“把 A 合进 B”，而是“把目标分支的变更合进当前所在分支”——切错分支，合并就彻底反了。
git merge 应该在哪个分支上执行
很多人执行 git merge feature 后发现代码没进 main，其实是人在 feature 分支上操作，结果把 main 合进了 feature。Git 永远只往当前 HEAD 所在分支里合。
- 要把
feature/login合入main：先git checkout main，再git merge feature/login - 要把
main的修复同步到dev：先git checkout dev，再git merge main - 执行前务必用
git status确认当前在哪个分支——别信记忆，信输出第一行 “On branch xxx” - 误合后若还没
push，可用git reset --hard HEAD~1撤回；已推远程则必须用git revert -m 1 <commit-hash></commit-hash>，否则污染他人历史
看到 “Already up to date” 却没代码？
这不是 Git 弄错了，是你本地分支没更新远程最新状态。git merge 只对比本地引用，不自动拉远程数据。
- 先运行
git fetch origin，把远程分支信息同步下来（不改工作区） - 再用
git log --oneline main..origin/main查看main落后多少提交 - 确认后执行
git merge origin/main，或直接git pull origin/main（注意：如果设过pull.rebase true，git pull行为会变成 rebase，团队协作中容易导致日志混乱） - 别跳过这步直接 merge —— 很多“奇怪冲突”其实源于本地分支太旧
冲突文件怎么快速定位和编辑
冲突发生时，Git 不报错，只是暂停并等你拍板。关键信号是 git status 输出里的 “Unmerged paths”，不是 IDE 高亮，也不是终端卡住。
- 运行
git status -s | grep "^UU"快速筛出所有冲突文件（UU表示 both modified） - 打开文件后看到的
、<code>=======、>>>>>> feature/name是 Git 插入的标记，不是你代码的一部分 - 删掉这三行只是清理动作；真正要干的是融合逻辑：函数参数要不要合并？JSON 字段要不要叠加？Python 缩进漏一行就可能让整个文件失效
- 别盲目用
git checkout --ours或git checkout --theirs—— 它们在 merge 和 rebase 中含义相反，且无法处理跨行耦合逻辑 - 超过 3 个冲突文件，优先配
git config --global merge.tool vscode，再跑git mergetool；它显示 LOCAL / BASE / REMOTE 三方内容，比纯文本扫更可靠
解决完冲突为什么 git commit 还失败？
删完标记 ≠ 解决完成。Git 还把文件标在“未合并”状态，必须显式 git add 才能移出暂存区。
- 每改完一个冲突文件，必须立刻
git add <file></file>；漏掉任意一个，git commit都会报fatal: cannot do a partial commit during a merge - 可以
git add .一键暂存，但要小心误加不该进本次合并的临时改动 - 确认全部冲突文件都已
git add后，再git commit（不加-m会弹出默认提交信息，含Merge branch 'xxx'） - 如果中途想放弃，用
git merge --abort；但它会丢弃所有已add的解决结果——动手前先git status记下哪些文件已解决，心里有数再 abort
最常被忽略的点：冲突不是错误，是 Git 主动暂停；但暂停之后那一步——git add——才是让 Git 认可“这事算完了”的唯一开关。漏掉它，一切白干。
