git报“refusing to merge unrelated histories”是因本地与远程无共同祖先提交，属安全保护机制；应优先用git pull --rebase origin main，或谨慎使用--allow-unrelated-histories并手动解决冲突。
远程分支提交被拒、拉取后一堆冲突、本地看不到远程已删分支——这些不是 Git 本身的问题，而是分支关联没建好、同步节奏乱了、或者合并策略选错了。
git pull 报错 “refusing to merge unrelated histories” 怎么办
这是本地仓库和远程仓库完全没有共同提交历史时的默认保护机制。常见于：你 init 了一个空本地库，又去 clone 远程已有 README 的仓库，再强行 push；或团队初始化时多人各自 init 后推送到同一远程。
- 临时解法：
git pull --rebase origin main（推荐）或git pull --allow-unrelated-histories origin main - 但更关键的是：以后别从空 init 开始。直接
git clone <url></url>拿完整历史 -
--rebase更安全——它把你的本地提交“重放”到远程最新提交之后，避免产生无意义的 merge commit - 如果已用
--allow-unrelated-histories合并过，后续所有git pull都会自动沿用该策略，无需重复加参数
为什么 git checkout -b dev origin/dev 比 git checkout dev 更可靠
因为后者只在本地找叫 dev 的分支，而前者明确基于远程 origin/dev 创建，并自动建立追踪关系（upstream）。
- 没建追踪：执行
git push会报错 “The current branch dev has no upstream branch”，必须写全git push origin dev - 建了追踪：
git push和git pull都能直接运行，Git 知道该同步到哪 - 验证是否建好：运行
git branch -vv，看dev行末尾是否有[origin/dev] - 补救方式：
git branch --set-upstream-to=origin/dev dev
多人在不同 feature 分支开发，最后合并到 main 时怎么避免隐性冲突
不是等 PR 提交完才检查，而是要在合并前主动把 main 的最新变更“吸进来”。否则两个功能分支各自基于旧 main 开发，合并时可能引入逻辑不兼容。
- 正确节奏：
git switch feat/login→git pull origin main --rebase（把 main 新提交 rebase 到你分支顶部）→ 测试 → 再提 PR - 别用
git merge main：它会产生一个 merge commit，污染功能分支历史，也掩盖真实变更点 - 如果
rebase过程中出现冲突，解决后用git add . && git rebase --continue，不是git commit - TortoiseGit 用户注意：右键 → TortoiseGit → Rebase 对话框里，务必勾选 “Keep rebase log” 才能看到每步操作
git push 被拒绝：“non-fast-forward” 是什么信号
说明你本地分支落后于远程，Git 拒绝覆盖别人已推送的提交。这不是错误，是保护机制。
- 最常见诱因：你
git pull之后又做了修改，但别人在你 pull 之后、push 之前也 push 了 - 立刻执行
git pull --rebase，把你的新提交挪到别人提交之后，再git push - 绝对不要
git push --force（除非你 100% 确认没人基于你的旧提交工作） - 如果用了
--force-with-lease，Git 会校验远程分支当前 HEAD 是否和你本地记录的一致，比--force安全得多
多分支协作里最常被跳过的一步，是每次开始开发前确认本地分支是否真正追踪了远程对应分支——git branch -vv 看一眼，花不了三秒，却能避开后面半小时的排查。
