git merge 命令应在目标分支（如 main）上执行，先 checkout 到该分支，再运行 git merge source-branch；若在 source 分支误执行，会将目标分支反向合并，导致逻辑错误。
合并分支到主干，本质是把变更合入你当前所在的分支，不是“往主干里塞”，所以切错分支就全乱了。
git merge 命令该在哪个分支上执行
Git 不会自动识别“主干”，git merge feature/login 总是把 feature/login 的变更合入你当前 HEAD 所在的分支。常见错误就是人在 feature 分支却执行 git merge main，结果把 main 合进了 feature，白忙活。
正确顺序只有一条铁律：
- 先
git checkout main（或master、develop等你定义的主干） - 再
git merge feature/login - 如果要同步远端主干到本地开发分支（比如把
main的 hotfix 推给dev），就先git checkout dev，再git merge main
合并前必须 clean 的三个动作
很多人合并失败，不是命令写错，而是环境脏：未提交修改、本地过时、冲突文件残留。不清理直接 merge，轻则报错中断，重则覆盖他人改动。
执行前务必跑通这三步：
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
-
git checkout main—— 确保在目标主干分支 -
git pull origin main—— 拉最新远端，避免本地落后产生非必要冲突 -
git status输出nothing to commit, working tree clean—— 如果有未提交修改，用git stash暂存（别用--hard丢弃，除非你确定）
merge vs. merge --squash：历史要不要留痕
默认 git merge feature 会保留 feature 上所有提交记录，适合多人协作、需追溯每个小改动的场景；git merge --squash feature 则把所有变更压缩成一个新提交，主干历史干净，但原始作者、时间、单次意图全部丢失。
选哪个，看团队规范和发布要求：
- 发版到
main或release/*分支，通常用--squash，避免杂乱提交污染主干 - 内部
develop合并日常功能，用默认 merge 更利于排查 -
--squash后不会自动 commit，得手动git commit -m "feat: login flow"，否则变更只是暂存状态
冲突解决后 push 前容易漏掉的关键检查
冲突解决完、git add、git commit 之后，别急着 git push。最常被跳过的一步是验证合并内容是否符合预期。
建议立刻做两件事：
-
git log --oneline --graph --all—— 看分支图，确认出现了双亲提交（或 squash 后的单提交），且指向正确 -
git diff HEAD~1 HEAD -- your/file.js—— 对关键文件，对比合并前后差异，防止误删、漏改或冲突标记残留（如） - 本地跑一次构建 + 关键路径测试，尤其注意跨分支改动的耦合点（比如 API 响应格式、数据库迁移脚本）
真正麻烦的不是 merge 命令本身，而是 merge 后那一堆没人细看的提交树、冲突标记残留、以及“我以为合进去了其实没合”的错觉。
