记一次 GitHub 幽灵协作者大清洗：强制重写 Git 历史与穿透 CDN 缓存实践

01. 诡异的背景：天降“幽灵”协作者
02. 刨根问底：幽灵账号究竟从何而来？
03. 核心痛点：为什么普通修改救不了命？
04. 终极解决方案（上）：地毯式重写 Git 历史
05. 终极解决方案（下）：硬核穿透 GitHub 顽固 CDN 缓存
06. 踩坑与避坑总结

01. 诡异的背景：天降“幽灵”协作者

不知道大家在日常开发中，有没有遇到过这样的场景：
你的个人开源项目，代码明明从头到尾全是你一个人一行行敲出来的，连个 Pull Request 都没接受过。但是，当你打开 GitHub 仓库主页时，右侧的 Contributors（协作者） 列表中，赫然躺着一个你完全不认识的陌生账号（比如叫 ghost_user 或者 unknown_developer 等等）。

如果你尝试去删除这个协作者，你会发现 GitHub 设置里根本没有删除入口。这简直就像代码仓库里住进了一个甩不掉的“幽灵”。今天，就带大家一文彻底解决这个疑难杂症，硬核清洗仓库历史。

02. 刨根问底：幽灵账号究竟从何而来？

为什么会有陌生人出现在你的 Contributors 列表里？罪魁祸首其实是你本地的 Git 配置。

GitHub 判定一次 Commit 属于谁，完全是看提交信息里的 Author Email。如果你在早期的本地电脑上，Git 的邮箱没有配置，或者使用了类似 test@example.com 这样的测试邮箱，又或者是使用了公司默认拼音邮箱：
一旦你把代码 Push 到了 GitHub，GitHub 就会去全网匹配这个邮箱 test@example.com 属于哪个注册用户。如果刚好有陌生人注册了这个邮箱，那么你的心血代码就这样被 GitHub 算作了他的贡献。

哪怕只有一次提交，他的头像也会永久挂在你的项目主页上。

03. 核心痛点：为什么普通修改救不了命？

很多同学发现问题后，第一反应是：

“我在项目里加个 .mailmap 映射文件不就行了？” （治标不治本，而且你的仓库会留下一份多余的配置文件）
“我用 git commit --amend 改掉最新一次提交行不行？” （不行，历史深处的提交依然是错误邮箱）
“那我把远程仓库删了重建？” （万万不可，这会丢失你珍贵的 Stars、Issues 和 PR 记录）

所以，唯一的完美解决路径是：利用底层脚本批量篡改所有的 Git 节点历史，然后强行覆盖远端，最后物理打穿 GitHub 的网页缓存。

04. 终极解决方案（上）：地毯式重写 Git 历史

想要改写历史，我们需要祭出 Git 的大杀器：git filter-branch。

4.1 拉取所有远程分支

很多时候你的旧提交不仅存在于 master，还藏在几十个老旧历史分支里。我们必须先把它们全拉到本地：

bash

复制代码

git branch -r | Select-String -NotMatch 'HEAD' | ForEach-Object { $branch = $_.ToString().Trim().Replace('origin/', ''); git checkout -b $branch "origin/$branch" }

4.2 编写与执行清洗脚本

使用以下脚本，遍历所有的分支和所有的标签（Tags），将历史中混入的脏邮箱，全部替换为你自己正确的邮箱：

bash

复制代码

#!/bin/sh
export FILTER_BRANCH_SQUELCH_WARNING=1
git filter-branch -f --env-filter '
CORRECT_NAME="your_real_name"
CORRECT_EMAIL="your_real_email@example.com"

if [ "$GIT_COMMITTER_EMAIL" = "test@example.com" ] || [ "$GIT_COMMITTER_NAME" = "WrongName" ]; then
    export GIT_COMMITTER_NAME="$CORRECT_NAME"
    export GIT_COMMITTER_EMAIL="$CORRECT_EMAIL"
fi
if [ "$GIT_AUTHOR_EMAIL" = "test@example.com" ] || [ "$GIT_AUTHOR_NAME" = "WrongName" ]; then
    export GIT_AUTHOR_NAME="$CORRECT_NAME"
    export GIT_AUTHOR_EMAIL="$CORRECT_EMAIL"
fi
' --tag-name-filter cat -- --branches --tags

核心提示（划重点）：
为什么一定要加 --branches --tags 参数？
因为如果在几十个分支上分别跑，会导致各分支原本共有的“祖先节点”产生不同的新 Hash，将来你合并代码时会面临大量的 Merge Conflict。加上这两个参数全局统筹，Git 的映射表（map）机制会保证分支拓扑树 1:1 完美平移，绝不产生无谓冲突。

4.3 强制覆盖远端

清理本地残留的备份，并将清洗后的树强制推送到远端：

bash

复制代码

rm -rf .git/refs/original/
git push --force --all origin
git push --force --tags origin

05. 终极解决方案（下）：硬核穿透 GitHub 顽固 CDN 缓存

如果你以为做完上面几步就结束了，那就错了。
当你再次打开 GitHub，你可能会发现：幽灵协作者还在页面上！

这是因为 GitHub 的底层数据库确实干净了，但它的网页前端用了 Fastly CDN，缓存极其顽固。对于仓库的 Contributors 列表，仅靠 Force Push 是无法触发全站 CDN 重算的。

我们需要使用**“休克疗法”**来打穿缓存。

方法一：默认分支反复切换（推荐）

如果你安装了 gh 命令行工具，可以通过反复切换默认分支，给 GitHub 服务器下达最高优先级的重算指令：

bash

复制代码

# 1. 创建一个临时分支并推送到远端
git checkout -b temp-refresh-branch
git push origin temp-refresh-branch

# 2. 调用 API 将默认分支切换为临时分支，强迫 GitHub 重算
gh repo edit --default-branch temp-refresh-branch

# 3. 等待15秒钟左右，再切回 master
sleep 15
gh repo edit --default-branch master

# 4. 销毁临时分支
git push origin --delete temp-refresh-branch
git branch -D temp-refresh-branch

方法二：空白分支覆盖（备选）

如果是单分支仓库，可以直接推送一个完全空的节点顶替 master，随后再恢复：

bash

复制代码

git checkout --orphan empty-tree
git rm -rf .
git commit --allow-empty -m "chore: clear history to reset github cache"
git push origin empty-tree:master --force
sleep 5
git checkout master
git push origin master --force

5.3 终极验证

直接调用底层 API 抓取真实数据验证，不要仅仅依赖浏览器的无痕窗口：

bash

复制代码

gh api repos/your_username/your_repository/contributors --jq '.[].login'

只要这个接口返回的 JSON 里只有你自己，就可以确认底层数据已彻底清理完毕。剩下的只需要等待 CDN 自然过期即可。

06. 踩坑与避坑总结

永远在新的电脑上配置好全局 Git 邮箱：git config --global user.email "your_real_email@example.com"。
大规模改写历史前，务必在本地打一个压缩包备份整个工程，防患于未然。
一定要检查 git ls-remote 看看是否有你本地没拉取过的古董分支，如果有，必须全部拉下来一起重写，否则错误记录随时可能死灰复燃。