答案是因执行了git merge --allow-unrelated-histories合并无共同祖先的第三方分支，导致主分支引入大量外来提交；应改用git subtree add或git format-patch+git am提取变更内容，而非直接合并历史。
为什么 git merge 会突然冒出一堆不认识的提交？
这不是 Git 报错，而是你执行了 git merge 一个与当前分支「无共同祖先」的第三方分支（比如从外部仓库 fork 后直接拉取、或用 git checkout --orphan 创建的分支），Git 拒绝自动合并，但你加了 --allow-unrelated-histories 强行合进来了——结果就是：主分支上凭空多出几十甚至上百个不属于你项目的提交，历史图谱炸开，git log --oneline 一眼望不到头。
如何安全剥离这些“外来提交”，只保留你关心的变更？
关键不是删掉它们，而是把「第三方分支带来的代码变更」提取出来，重放到你自己的历史线上。本质是做一次「内容级 cherry-pick」，而非历史级合并：
- 先确认第三方分支的起点：运行
git merge-base --octopus HEAD origin/third-party-branch，如果输出为空，说明确实无共同祖先 - 找出你真正想保留的变更范围：用
git diff origin/third-party-branch -- <path></path>看它改了哪些文件（尤其关注配置、依赖、脚本等非业务代码） - 不 merge，改用
git subtree add --prefix=vendor/third-party origin/third-party-branch main—— 这会把整个第三方历史收进子目录，不污染主历史，后续更新也只需git subtree pull - 若必须平铺到根目录（比如要 patch 主项目源码），则用
git format-patch -o /tmp/patches origin/third-party-branch --no-commit生成补丁，再手动git am /tmp/patches/*.patch应用（跳过 commit 元信息，只取变更内容）
rebase 能不能直接“过滤掉”无关提交？
不能。rebase 的目标是重放「已有提交」，而这些外来提交根本不在你的引用链里——它们是被 --allow-unrelated-histories 硬塞进来的独立子图。强行 git rebase -i 会看到大量 pick 行对应那些陌生提交，删掉它们等于丢弃所有变更，不是你想要的结果。
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
真正该做的是：用 git replace 或 git filter-repo 重构历史（仅限未推送的本地分支）；但更务实的做法是——立刻停用该合并，切回上一个干净的 HEAD（查 git reflog 找到 merge 前的 commit），然后换用 subtree 或 submodule 方式集成第三方代码。
最容易被忽略的危险点
很多人以为加了 --allow-unrelated-histories 就万事大吉，却忘了检查这些外来提交是否包含：.gitmodules 文件、硬编码的 API 密钥、调试用的 console.log 或 print()、已废弃的构建脚本。它们不会报错，但会在 CI 流水线或生产环境里悄悄埋雷。务必在合并后立即运行 git grep -n "TODO\|FIXME\|console\.log\|os\.getenv" -- . 快速扫描。
