卡住的时候回来查：开发向常见问题

为什么会这样

你两边都各自往前走了一步。用第 2 篇的比喻说：档案馆里出现了两册各自往下写的草案，Git 不替你决定该用哪种方式把它们并成一册，所以停下来问你。

再仔细看 pull 的输出——它其实抓取成功了（你能看到类似 <旧哈希>..<新哈希> master -> origin/master 的一行），只是没有合并。而 push 被拒是连带的：你本地还不包含远端那些提交，硬推上去会覆盖掉另一台机器的工作，Git 直接拦下。

merge 还是 rebase

怎么做（新手选 merge）

git config --global pull.rebase false
git pull origin master
git push origin master

中间会弹出编辑器让你写一句合并说明，保存退出即可（弹出来出不去，见本页下一条）。

怎么确认真的同步上了

三种硬证据，可靠度递增：

git rev-parse HEAD origin/master

git show origin/master:<项目说明文件> | grep -n "<你新增的章节标题>"

git --no-pager log --oneline --graph -8

第一条最硬：两个哈希完全一样就是同步了。第二条直接读远端分支上的文件内容，证明东西真的推上去了。第三条看图——|\ 是分开、|/ 是合上，三个指针落在同一处就是同步：

*   a1b2c3d (HEAD -> master, origin/master) Merge branch ...
|\
| * e4f5a6b  另一台机器的提交
* | 7c8d9e0  你的提交
|/
* 1122334  共同起点

为什么会这样

中文输入法下按 : 打出来的是全角的 ：，编辑器不认识它；按 Esc 又可能被输入法先吃掉（它拿去取消候选词了），根本传不到编辑器。

怎么做

• 保存退出：Esc → :wq → 回车
• 放弃退出：Esc → :q! → 回车
• 误输入了内容：Esc → u（撤销）→ 再 :wq

治本（建议直接做）

git config --global core.editor nano

nano 底部常驻显示快捷键（^O 保存、^X 退出），不分模式，输入即所见。vim 很强大，但它的学习曲线不该出现在"我只是想写一句合并说明"这种场景里。

合并时也可以干脆跳过编辑器：

git pull --no-edit origin master

为什么会这样

托管平台允许仓库换地址——改个名、转到组织名下、或者换个账号托管，都会让地址变一次。为了不让别人手上的旧副本突然失联，平台会把旧地址自动重定向到新地址。

这是个善意的设计，代价藏在后面：一个几个月前克隆下来的旧文件夹，今天你在里面 pull、push 依然全部成功，回显跟平时一模一样。它连的是旧地址，而旧地址被悄悄转到了新地址——所以你的改动确实推上去了，只是你人站在另一个文件夹里，改的是另一份副本。

先确认你站在哪儿

pwd
git remote -v

第一条告诉你此刻在哪个文件夹，第二条告诉你这个文件夹连的是哪个仓库地址。先看清楚这两个，再动手改任何东西。

怎么收拾

一台机器上，一个项目只留一个工作目录。多出来的那些这样处理：

• 逐个进去跑上面那两条命令，认出哪个是你现在真正在用的；
• 其余的先整体打包备份一份，别直接删——里面可能有你以为已经推上去、其实还躺在本地的改动；
• 备份完，把多余的删掉。

为什么会这样

git branch -d 会先做一道安全检查，问的是：这个分支上的提交，别处已经收进去了吗？如果没有，删掉就等于把工作丢了，所以它拦下来。

问题在于「别处」指哪儿。你的分支若推到过远端（用 -u 推的那次就会设上），这道检查比对的就是远端那条线；而你的合并发生在主干上。两条线不是同一条，于是检查没通过。

提示里那半句 "even though it is merged to HEAD" 正是 Git 在告诉你：它知道你已经合进当前所在的主干了，但它检查的不是这个。它不是在跟你唱反调，是在说清楚自己刚才量的是什么。

先证明它真的可以删

git log origin/main..feat/your-branch

这条命令问的是：这个分支上，有没有主干还没有的提交？没有任何输出，就是没有——分支上的东西主干全都有了，删它不会丢任何工作。

确认之后再删

git branch -D feat/your-branch

大写的 -D 表示跳过那道检查。顺序不能反：先用上面那条命令拿到「零输出」这个证据，再用 -D。