提交代码和合并到目标分支是两个独立动作，必须先 git add 和 git commit 生成本地提交，才能执行 git merge 或 git push；git push 仅同步已有提交，不替代提交操作。
直接说结论：提交代码和合并到目标分支是两个独立动作，不能跳过“先提交到本地分支”这一步就去合并；多数人卡住，是因为在没 git add 和 git commit 的情况下，直接对空工作区执行 git merge 或 git push，结果什么都没发生。
为什么 git push 不等于“提交代码”
很多人以为敲完 git push 就算把代码交上去了，其实它只负责把**本地已有提交**推送到远程仓库。如果本地还没 git commit，git push 会提示 “Everything up-to-date” 或直接报错“Nothing to commit”。
Git 的提交流程是线性的：修改文件 → git add（暂存）→ git commit（生成本地提交）→ git push（同步到远程）。漏掉中间任一环，后续操作都会失效。
合并前必须确认的三件事
执行 git merge 前，当前所在分支、目标分支、本地提交状态必须清晰，否则容易合并错分支或覆盖他人改动：
- 用
git branch确认当前分支（带*号的是你正在操作的分支） - 用
git log --oneline -3看最近几条本地提交，确保你要合并的内容已commit进去 - 用
git fetch origin拉取远程最新状态，再用git log origin/main --oneline -3对比远程main是否有新提交（避免你基于旧基线合并）
merge 时最常踩的三个坑
git merge 表面简单，但实际出问题往往不是命令不会输，而是上下文没理清：
- 在
feature分支上误执行git merge main：这会把main合进feature，而不是你想的“把feature合进main”。正确做法是先git checkout main，再git merge feature - 没
git pull origin main就直接合并：如果别人刚往main推了新提交，而你本地还停留在旧版本，git merge feature可能触发非预期的三方合并，甚至掩盖冲突 - 合并后忘记
git push origin main：git merge只改本地分支指针，不自动推送到远程；不推，别人就看不到你的合并结果
什么时候该用 cherry-pick 而不是 merge
如果你只想把另一个分支里的某几个提交搬过来（比如修复了一个线上 bug，但不想把整个 feature 分支都合进来），git merge 就不合适了——它会把目标分支从分叉点开始的所有提交一股脑合并进来。
这时应该用 git cherry-pick：
- 先
git checkout main - 再
git cherry-pick abc123（把feature分支中哈希为abc123的那个提交单独拎过来） - 如果要搬多个不连续提交：
git cherry-pick abc123 def456 - 如果要搬连续一段：
git cherry-pick start^..end（注意^表示“不包含起点”，这是易错点）
cherry-pick 生成的是新提交（哈希值不同），不会保留原提交的作者时间戳，但能精准控制引入范围——适合补丁场景，但不适合日常功能交付。
真正麻烦的从来不是命令本身，而是搞不清“我在哪、我要从哪来、我要到哪去”。每次执行 git merge 或 git cherry-pick 前，花十秒看一眼 git status 和 git log --graph --oneline -5，能避开 80% 的合并事故。
