必须先 checkout 目标分支，因为 git merge 是将指定分支合并到当前所在分支，而非“把当前分支合入目标分支”；例如将 feature/login 合入 main，须先 git checkout main 再 git merge feature/login。
git merge 之前必须先 checkout 目标分支
Git 不允许你在当前分支上直接“把另一个分支合进来”而不明确指定“合到哪去”。git merge feature/login 这条命令的意思是“把 feature/login 合并到当前所在分支”，不是“把当前分支合并到 feature/login”。所以，想让 feature/login 的改动进入 main，你得先切到 main，再执行 merge。
常见错误：在 source 分支上直接 merge source
比如你在 feature/login 分支里运行：git merge main，结果就是把 main 合进 feature/login —— 方向反了，而且可能引入不该有的历史。这种操作在 PR 场景下尤其危险，会导致远端 main 被污染（如果误 push）。
- 现象：执行完 merge 后发现
git log显示main的提交出现在feature/login的历史里 - 原因：没切分支，merge 目标错了
- 验证方法：执行
git branch看星号在哪，或git status第一行明确写 “On branch xxx”
正确操作链：checkout → merge → push
以将 feature/login 合入 main 为例：
用大白话操作当前项目的 Git/GitHub——配置 GitHub（装 gh CLI + 登录 + 建仓库）、备份、拉取下载、查询历史、回滚代码、管理分支。当用户用日常语言表达 git 意图时触发（例如"git备份一下""git下载项目""git拉下来""git看看我改了啥""git回退到上一个版本""git新建个分支搞新功能""git合并到主分支""git
-
git checkout main（或git switch main，推荐后者，更语义清晰） -
git pull origin main（确保本地main是最新，避免快进失败或隐藏冲突） -
git merge feature/login（此时 merge 的目标就是main） - 如有冲突，解决后
git add . && git commit -
git push origin main（把合并结果推上去）
为什么不能跳过 checkout 直接指定目标？
Git 的设计哲学是「当前工作区即上下文」。它不提供类似 git merge --into main feature/login 这种语法，因为这会模糊“谁在修改谁”的责任边界。所有变更都必须发生在明确的、可追踪的当前分支上。这也让 rebase、reset、reflog 等操作的行为更可预测。顺带一提：git merge 默认使用 --ff（快进），但如果目标分支有新提交，就会转为创建 merge commit——这个行为也只在你 checkout 到目标分支后才生效。
