git merge 应在目标分支上运行，即先 checkout 目标分支（如 main），再执行 git merge 源分支，否则代码流向会反向导致历史污染。

必须在目标分支上执行 git merge，否则代码流向会完全反向——这是 90% 合并出错的根源。

git merge 应该在哪个分支上运行

Git 不会自动判断“要把 A 合进 B”，它只认当前 HEAD 所在分支。执行 git merge feature 的结果，永远是“把 feature 的改动合入当前分支”。

• 要把 feature/login 合入 main：先 git checkout main，再 git merge feature/login
• 要把 main 的修复同步到 dev：先 git checkout dev，再 git merge main
• 误在 feature 上执行 git merge main，结果就是 main 被合进了 feature——这不是“同步”，而是污染了功能分支的历史
• 执行前务必用 git status 确认第一行显示的是目标分支（如 On branch main），别信记忆，尤其在多人协作时

合并前必须做的三件事

跳过清理步骤，后续冲突概率陡增，且容易把本地脏修改一起带进主干。

openclaw-gitcode-pr-monitor

监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。

下载

• git checkout main —— 切到目标分支
• git pull origin main —— 拉取远程最新，避免因本地落后产生“伪冲突”
• git status 看是否干净；如有未提交改动：
  • 临时保存用 git stash（推荐）
  • 彻底丢弃用 git reset --hard && git clean -fd（慎用）

解决 Automatic merge failed 冲突的实操要点

冲突不是错误，是 Git 在告诉你：“这两边改了同一块逻辑，得你来拍板”。卡住、没报错、没提示？很可能是已经成功合并但你没注意输出里有没有 Merge made by the 'ort' strategy 或 Already up to date。

• 冲突发生后，git status 会明确列出 Unmerged paths，每行带 both modified: 标识——这些才是真要打开编辑的文件
• 别只靠 IDE 图形界面：VS Code 有时不刷新冲突标记，或把已 git add 的文件仍标为冲突
• 快速过滤冲突文件：git status -s | grep "^UU"
• 编辑时删掉 、<code>=======、>>>>>> feature 这三行标记，但**不能随意删掉其中一方代码**——得根据业务逻辑决定保留、合并还是重写
• 解决完必须严格按顺序执行：git add <file></file> → git commit（不加 -m 会弹出默认信息，含 Merge branch）→ git push；漏掉 git add，git commit 会直接报 fatal: cannot do a partial commit during a merge

merge --squash 和普通 merge 的关键区别

选哪种不取决于“好不好用”，而取决于团队对历史可追溯性的要求。

• 普通 git merge feature：保留 feature 分支所有原始提交记录，适合多人协作、需审计、要回溯单次改动的场景
• git merge --squash feature：把 feature 上所有变更打包成一个新暂存区，需手动 git commit；历史里只留一个提交，看不到原始分支脉络——适合小功能、临时补丁、或上线前强制收口
• --squash 后不会自动 commit，git status 显示的是 “Changes to be committed”，不是 “merged” 状态；必须自己 git commit -m "xxx"
• 快进（fast-forward）合并不产生新提交，只是移动指针；加 --no-ff 可强制生成双父提交，留下明确合并痕迹，方便后期用 git log --oneline --graph 查看结构

最容易被忽略的一点：git merge --abort 只在还没 git commit 前有效；一旦提交完成，想撤回就得用 git revert，而不是 reset——后者会改写已推送到远程的历史，影响他人工作。