一、起因
今天我在 dev 分支上想做一件最稀松平常的事：
git pull
终端却抛出错误：
fatal: refusing to merge unrelated histories
「拒绝合并无关历史」——意思是 Git 觉得本地 dev 和远端 origin/dev 像两条陌生的河流，不愿意把它们汇成一股。
二、先别动手，先看清楚
遇到这种情况，第一反应不该是 --allow-unrelated-histories 之类的「魔法开关」，而是把事实先摸清楚。我跑了一组只读命令：
git status
git remote -v
git branch -vv
关键信息只有一行：
* dev <local-sha> [origin/dev: ahead 83, behind 89] <commit message>
翻译成人话：
- 本地
dev领先远端 83 个提交； - 同时又落后远端 89 个提交；
- 也就是说两边各自走了一段路，已经分叉得相当严重。
再叠加 git pull 的「unrelated histories」错误，基本可以判断：远端 dev 在某个时间点被重写过历史（可能是 force push 或者重建分支），导致两边连共同祖先都难以匹配。
此外 git status 还显示了几个未跟踪文件（个人配置目录、若干服务端模块和一些样例 JSON），这些是工作区里我自己加的东西，与远端无关，待会儿要确保它们安全。
三、决策：保留谁的历史？
摆在面前有三条路：
git merge --allow-unrelated-histories：把两边强行汇合。代价是产生大量冲突，并且会留下一坨噪音提交。git rebase origin/dev：把本地 83 个提交逐个改写到远端历史之上。冲突只会更多，而且若两边真的「无关」，rebase 也救不回来。- 直接放弃本地分支，以远端为准：本地 83 个提交永久从分支上消失，但工作树立刻干净。
由于这次本地 83 个提交里没有真正需要保留的成果（都是已经被远端用别的方式覆盖掉的工作），我选择了第 3 条路。
经验：当「保留本地分支」的代价（解决大量冲突 + 留下混乱历史）大于「重做」时，果断重置往往是最经济的选择。
四、执行：fetch + 硬重置
确认决策后，操作其实只有两步：
git fetch origin
git reset --hard origin/dev
git fetch origin：把远端最新的引用拉到本地，但不动工作树。git reset --hard origin/dev：把当前分支指针、暂存区、工作树一次性重置到origin/dev。
执行完毕后：
HEAD is now at <remote-sha> <commit message>
再检查一次状态：
git status
git log --oneline -5
输出：
On branch dev
Your branch is up to date with 'origin/dev'.Untracked files:(use "git add <file>..." to include in what will be committed)<local-only config dir><sha> <commit message>
<sha> <commit message>
<sha> Merge branch 'dev' of <internal-host>:<org>/<repo> into dev
<sha> <commit message>
<sha> <commit message>
几个值得说明的细节：
- 本地分支已经和
origin/dev完全同步。 - 本地新增的个人配置目录仍然作为未跟踪文件保留下来——
git reset --hard不会删除未跟踪文件，这正是我们想要的行为。 - 之前列在「未跟踪」里的若干服务端模块和样例 JSON 这次都「消失」了——并不是被删除，而是远端已经把它们作为正式跟踪文件提交了进来，本地副本被远端版本覆盖。
五、容易踩的坑
- 误以为日志里那条
fix是我自己修的提交。其实那是远端最近一次提交的 commit message，跟本次操作无关。复盘时一定要分清「我做了什么」和「我看见了什么」。 git reset --hard不可逆？——并不完全是。被丢弃的 83 个提交在本地仓库里还会保留在reflog里一段时间（默认 30~90 天），可以用git reflog找回 commit hash，再git branch rescue <hash>拉一条救援分支出来。但 reflog 是本地的，别指望它能在另一台机器上救你。- 未跟踪文件的命运：硬重置不动它们，但
git clean -fd会一次性清空它们。两个命令一定要分清，不要混着用。 - 直接
git pull --allow-unrelated-histories的诱惑：在分叉超过几十个提交时，这条路几乎一定会演变成「连续解几十个冲突 + 一个垃圾合并提交」，远不如先看清楚再决定。
六、流程上的反思
这次故障本身是 30 秒就能修好的小事，但暴露了一个团队层面的问题：有人在 dev 上做了重写历史的操作（force push 或重建），却没有同步给所有协作者。下游的人就会在某个早晨突然遇到 refusing to merge unrelated histories。
后续可以：
dev这种共享分支默认禁止 force push（GitHub 上加 branch protection rule）。- 如果确实必须重写历史，提前在群里通知，并要求大家执行
git fetch && git reset --hard origin/dev之前先备份未提交的工作。 - 个人层面：在本地
dev上长期囤积大量未推送的提交本身就是一种风险。日常应当尽快推送或者切到 feature 分支隔离。
七、TL;DR
# 1. 看清楚状态
git status
git branch -vv# 2. 拉取远端引用（不动工作树）
git fetch origin# 3. 以远端为准，强行覆盖本地分支
git reset --hard origin/dev# 4. 确认结果
git status
git log --oneline -5