Anonymous GitHub —— 一键匿名化你的代码仓库（助力学术双盲评审）

1. 为什么你需要一个“匿名”的代码仓库？

如果你是一名研究生、博士生，或者正在向顶级学术会议（比如NeurIPS、ICLR、CVPR）或期刊投稿，那么你对“双盲评审”这个词一定不陌生。简单来说，就是审稿人不知道你是谁，你也不知道审稿人是谁。这个制度的初衷非常美好，就是为了最大限度地保证评审的公平性，避免作者的名气、机构背景等因素影响对论文工作本身的判断。

理想很丰满，但现实往往有点骨感。很多会议和期刊在要求提交论文的同时，还要求你公开实验代码和数据，通常就是提供一个GitHub仓库的链接。问题来了：你的GitHub个人主页、你的仓库提交历史（commits）、甚至代码文件里的注释，很可能到处都是你的真实姓名、邮箱、学校或公司名称。你总不能提交一个链接，然后对审稿人说：“老师您好，请忽略主页上我的名字和照片，以及每个commit记录里的Author: Zhang San <zhangsan@xxx.edu>，只看代码就好。” 这显然就破坏了双盲的原则。

以前大家是怎么做的呢？我见过也干过不少“土办法”。最常见的就是临时注册一个新的GitHub账号，起个毫无意义的用户名，然后把代码仓库原样复制过去。这个方法听起来简单，实则麻烦一堆。首先，你得管理一堆“一次性”小号，时间一长自己都忘了密码。其次，有些会议要求代码仓库必须在投稿截止日期前创建并保持可访问，这意味着你这个临时小号得一直维护着。更头疼的是，如果你的工作后续中了，需要把代码正式开源到主账号，又涉及到仓库迁移、链接更新等一系列操作，非常琐碎。

所以，当我第一次发现Anonymous GitHub这个工具时，感觉就像找到了救星。它的核心思路非常直接：它不改变你原有的仓库，而是为你生成一个“镜像”页面。在这个镜像里，所有你指定需要隐藏的个人信息（比如名字、机构、邮箱），都会被统一替换成“XXX”之类的占位符。审稿人通过你提供的这个特殊链接访问到的，就是一个已经“洗”掉了作者身份的代码仓库。你的主仓库安然无恙，双盲评审的要求也得到了满足，一举两得。

2. Anonymous GitHub 实战：手把手教你生成匿名链接

光说概念可能还有点虚，我们直接上手操作一遍，你就全明白了。整个过程完全在网页端完成，不需要你安装任何软件。

2.1 第一步：访问工具并选择匿名化模式

工具的官方地址是https://anonymous.4open.science。打开后，你会看到三个选项，这对应了三种不同的匿名化策略：

1. Anonymize a GitHub repository：这是最常用、也是最核心的功能。你提供一个公开的GitHub仓库地址，工具会去抓取内容，处理后再生成一个匿名化的静态页面。
2. Anonymize a Git repository：如果你的代码仓库不在GitHub上（比如在GitLab、Bitbucket，或者就是你本地的一个Git文件夹），你可以先把它打包成一个.zip文件，然后上传到这里进行处理。
3. Anonymize a DOI：这个比较特殊，是针对已经通过某些学术数据平台（如Zenodo）获得了DOI（数字对象标识符）的代码存档进行匿名化。适合那些已经将代码作为论文补充材料正式发布的情况。

对于我们大多数应对论文投稿的场景，直接选第一个就好。接下来，你需要把你想要匿名化的那个公开GitHub仓库的URL贴进去。比如你的仓库地址是https://github.com/YourName/YourPaperCode，就完整地复制过来。

2.2 第二步：精心设置你的“敏感词”列表

这是整个过程中最关键、也最需要你细心的一步。工具的工作原理是文本替换，它会把你提供的“敏感词列表”里的所有词汇，在代码、文件内容、甚至是文件名中，全部替换成“XXX”。

那么，这个列表里应该放些什么呢？我根据自己的踩坑经验，给你整理了一个必查清单：

• 作者姓名：你的中文名、拼音名、常用的英文名。比如“张三”、“San Zhang”、“Alex”。
• 机构名称：你的大学、实验室、公司的全称和缩写。例如“北京大学”、“Peking University”、“PKU”、“Microsoft Research”。
• 邮箱地址：你常用的、可能出现在代码注释或配置文件里的邮箱。zhangsan@college.edu。
• GitHub用户名：这个特别容易漏！你的主账号ID，以及你可能在代码里引用到的其他合作者的GitHub ID。
• 项目内部名称：如果你的代码里有一个给项目起的内部代号（比如“Project Phoenix”），而这个代号在论文里被隐去了，那最好也加进来替换掉。
• 特定路径或文件名：有些路径可能包含你的用户名，比如/home/zhangsan/data/。如果你在代码里用绝对路径或写死了这类路径，也需要考虑。

怎么找全这些词呢？最笨但最有效的方法，就是在你的本地仓库里，用全局搜索（grep -r命令）去搜你的名字、邮箱、学校名。在命令行里，你可以这样操作（假设你在仓库根目录）：

# 搜索所有文件中的“YourName” grep -r -i "YourName" . --include="*.py" --include="*.md" --include="*.txt" --include="*.json" # 搜索所有文件中的邮箱模式 grep -r -E "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b" .

把搜出来的这些词，一条一条地填进工具页面的那个文本框里，每行一个。这一步宁可多，不可少。多替换一个无关紧要的词顶多让审稿人看到多几个“XXX”，但漏掉一个真名，双盲就失效了。

2.3 第三步：设置有效期与生成

填好敏感词列表后，下面有一个设置有效期的选项。这里通常有三种选择：

• Keep forever：永久保存。这个匿名链接会一直有效。
• Remove the repository after a specific date：在特定日期后自动删除。你可以设置为论文评审结束后的某一天，非常贴心。
• Redirect to the original GitHub repository after a specific date：在特定日期后，这个匿名链接会自动跳转回你原始的GitHub仓库。这适合论文被接收后，你想把审稿用的匿名链接直接变成你正式的开源链接。

我个人的习惯是选择第二个，设置一个未来3-6个月的删除日期。因为一旦论文被接收，我通常会好好整理一下代码，写个更清晰的README，再正式开源到主账号下。那个临时生成的匿名页面就完成它的历史使命了。

点击提交后，工具就会开始工作。它会克隆你的仓库，遍历每一个文件，执行替换操作。这个过程可能需要几十秒到几分钟，取决于你仓库的大小。处理完成后，你会获得一个独一无二的URL，格式长这样：http://anonymous.4open.science/repository/840c8c57-3c32-451e-bf12-0e20be300389/

这个链接，就是你最终可以放心提交给会议系统的“匿名仓库”地址了。你可以自己先点开看看，检查一下替换效果是否彻底。

3. 深入原理：它到底是怎么工作的？

用起来很简单，但了解它背后的原理，能帮你更好地使用它，也能明白它的局限性。Anonymous GitHub 本质上是一个静态网站生成器，只不过生成的内容是你代码仓库的“匿名化快照”。

当你提交仓库地址和敏感词列表后，后台会发生这几件事：

1. 克隆与抓取：服务器端的脚本会使用git clone命令，将你指定的公开仓库完整地下载到临时空间。
2. 深度扫描与替换：接着，一个处理程序会遍历仓库里的每一个文件，包括代码文件（.py,.java,.cpp）、文本文件（.md,.txt）、配置文件（.json,.yaml）等等。它使用你提供的敏感词列表，对文件内容进行全文匹配和替换，把匹配到的词统统换成“XXX”。这个替换是大小写不敏感的，所以不用担心大小写问题。
3. 生成静态文件：替换完成后，它并不是重新建一个Git仓库，而是把处理后的所有文件，生成一套静态的HTML页面。这就像用Jekyll或Hugo把Markdown博客变成网站一样。你的代码文件会以高亮的形式展示，目录可以浏览，但底层已经没有Git版本库了。
4. 提供访问服务：最后，这套静态页面被部署在一个特定的URL路径下，供任何人通过浏览器访问。

正因为最终产物是静态页面，所以它带来了一个最大的优点：安全且无残留。审稿人只能通过浏览器看代码，无法通过git clone命令获取原始的Git历史记录，从而彻底杜绝了从commit历史、作者信息中泄露身份的可能。

但这也引出了它目前最主要的局限性：审稿人无法直接克隆（clone）这个匿名仓库到本地运行。他们只能浏览、阅读和下载单个文件。这对于需要复现实验的评审来说，确实带来了一些不便。审稿人需要手动点击下载每个文件，或者使用页面提供的“Download ZIP”功能下载整个快照，然后在本地解压、配置环境。虽然多了几步操作，但为了双盲的严肃性，这个代价在多数情况下是可以接受的。工具的作者也在项目Issue里解释过，要实现一个可克隆的、同时又能匿名化所有历史信息的Git仓库，在工程上非常复杂，目前没有精力重构。

4. 超越基础：让你的匿名化更彻底的实用技巧

仅仅依靠工具的自动替换可能还不够“保险”，因为有些个人信息可能以意想不到的形式存在。结合我自己的经验，我强烈建议你在运行Anonymous GitHub工具之前，先对自己的仓库做一次彻底的手动清理。你可以把这看作是一次代码发布的“预演”。

技巧一：彻底扫描提交历史（Git History）工具的替换只针对当前代码快照，但Git仓库的灵魂——提交历史——里充满了“黑历史”。你需要检查以往的commit信息里有没有暴露身份。在仓库根目录运行：

git log --oneline

逐条查看commit message。如果发现早期的commit里有真名或敏感信息，可以考虑使用git rebase -i来交互式地修改历史commit，或者更干净的做法是，为投稿新建一个分支，然后在这个分支上使用git filter-branch或git filter-repo（推荐，更安全）这样的核武器级工具，彻底重写所有历史记录，抹去作者信息。不过，操作Git历史有风险，务必先备份。

技巧二：清理配置文件与元数据很多IDE或编辑器会在项目中生成隐藏的配置文件，比如.vscode/、.idea/目录，里面可能包含你的本地工作区路径。一些数据文件，如.DS_Store(Mac)、Thumbs.db(Windows)，也可能包含系统用户名。在打包或上传前，最好使用.gitignore文件忽略它们，或者直接删除。

技巧三：检查代码中的“硬编码”仔细检查你的代码，特别是配置文件、参数设置文件和实验脚本。有没有把本地数据集路径写成/Users/YourName/Documents/data/？有没有在注释里写“这个技巧是我导师XXX教授教的”？把这些都找出来，要么改成相对路径，要么用占位符替换。

技巧四：善用.gitattributes文件你可以创建一个名为.gitattributes的文件，并加入如下内容：

*.py filter=anon *.md filter=anon

然后在本地Git配置中设置一个“clean”过滤器，让Git在提交（git add）时自动调用脚本替换敏感词。这样可以从源头保证进入仓库的内容就是干净的。不过这个方法需要一些脚本编写能力，属于进阶玩法。

做完这些手动清理，再把你清理过程中发现的所有新敏感词，补充到Anonymous GitHub的替换列表里，最后生成的匿名页面，其干净程度会大大提升，让你在提交时更加安心。

5. 常见问题与替代方案探讨

在使用过程中，你可能会遇到一些疑问，我这里集中解答一下：

Q：我的仓库是私有的（Private），能用这个工具吗？A：不能。这个工具的工作原理要求它能公开访问并克隆你的仓库。如果你的仓库是私有的，它无法获取内容。解决方案是，你可以临时将仓库设置为公开（Public），生成匿名链接后，再改回私有。或者，使用它的第二个功能，将私有仓库打包成ZIP（注意打包前做好手动清理），然后上传ZIP文件进行处理。

Q：匿名化后的代码，审稿人如何复现实验？A：正如前面提到的，由于无法git clone，复现步骤确实变多了。为了帮助审稿人，你必须在匿名仓库的README.md文件里，提供极其清晰、一步步的“手动安装与运行指南”。要假设审稿人拿到的是一个ZIP压缩包，告诉他：

1. 解压ZIP到何处。
2. 如何安装依赖（精确的pip install -r requirements.txt命令或环境配置说明）。
3. 如何准备数据（提供数据下载的公开链接或生成模拟数据的脚本）。
4. 如何运行主要的训练或评估脚本（给出具体的命令行示例）。 写得越傻瓜式，审稿人体验越好，你的论文获得公平评审的机会也越大。

Q：除了Anonymous GitHub，还有别的办法吗？A：有一些思路，但各有利弊。

• 新建空白账号：最传统的方法，前面提过，管理麻烦。
• 使用Git服务商的“匿名克隆”功能：有些平台（如GitLab）有生成“匿名克隆URL”的功能，但通常只是隐藏了认证信息，仓库内容本身不变。
• 自行搭建中间代理服务：技术高手可以写个脚本，自动从原始仓库拉取代码，进行文本替换，然后推送到一个“中转”仓库。但这需要服务器和维护成本。
• 在论文中提供代码片段而非完整仓库：有些会议允许这样做，但这不利于可复现性。

综合来看，对于绝大多数研究者，Anonymous GitHub仍然是平衡了便捷性、安全性和成本的最佳选择。它完美地解决了“展示代码”和“隐藏身份”这个核心矛盾。虽然它在交互性上有一点妥协，但通过提供详尽的文档，完全可以弥补。说到底，双盲评审的核心精神是消除偏见，让工作本身说话。这个工具，正是守护这份公平性的一个非常实用的技术助手。