git merge 作用是将指定分支的更改合并到当前 head 所在分支，必须先切换至目标分支（如 main）再执行合并，顺序错误会导致历史混乱；合并后需手动 push 才能同步到远程。
远程分支合并不是“把代码推过去”，而是本地完成 merge 后再 push —— 顺序错一步，历史就乱了。
git merge 必须在目标分支上执行
Git 不认“你想合到哪”，只认 HEAD 当前所在分支。比如要把 feature/login 合入 main：
- ✅ 正确：先
git checkout main（确认git status显示 “On branch main”），再git merge feature/login - ❌ 错误：在
feature/login分支上执行git merge main—— 这会把main合进功能分支，逻辑完全反了 - ⚠️ 已 push 的错误合并不能用
git reset --hard，必须用git revert -m 1 <merge-commit-hash></merge-commit-hash>反转，否则会破坏他人本地历史
git pull --ff-only 是最安全的同步方式
默认 git pull 可能悄悄创建合并提交，污染线性历史。强制快进才是协作底线：
- ✅ 推荐：日常同步用
git pull --ff-only origin main—— 若本地main已分叉，直接报错，逼你停下来处理分歧 - ✅ 配合
git fetch origin && git log --oneline main..origin/main可预览差多少提交，提前判断是否需要变基或沟通 - ⚠️ 如果本地
main有未推送的提交，--ff-only一定失败 —— 这不是 bug，是提醒你该决策了（变基 or 协调）
冲突文件必须用 git add 显式标记解决
编辑器里删掉 、<code>=======、>>>>>> feature/login 三行只是第一步，Git 完全不感知“你修好了”：
- ✅
git status会明确列出 “Unmerged paths”，这是唯一可信依据 - ✅ 改完一个冲突文件后，必须
git add <file></file>，否则git commit会拒绝并提示 “fix conflicts and run git commit” - ⚠️
git merge --abort会丢弃所有已add的解决状态 —— 真要放弃前，先记下哪些文件已add - ⚠️ 别依赖 IDE 的“一键解决”，尤其涉及逻辑合并（如两边都加了同名函数但参数不同），手动核对才是底线
合并后必须清理本地和远程分支
本地 git merge 成功只是第一步，不推、不删，协作链就断在你这里：
- ✅
git push origin main推送合并结果（假设目标是main） - ✅
git branch -d feature/login安全删除本地分支（-d检查是否已完全合并，未合并会拒绝） - ✅
git push origin --delete feature/login手动删远程分支 —— Git 从不自动同步这个动作 - ⚠️ 如果远程分支被别人还在用，删之前务必确认（比如看 CI 状态、问 Slack 频道），否则可能打断别人构建
最容易被忽略的是：远程分支删除后，本地仍会显示 origin/feature/login —— 那只是缓存，不是真实存在。要用 git fetch --prune 或 git remote prune origin 清理，否则下次 git branch -r 还会看到它。
