2026 年 4 月 24 日， GitHub 的模型训练政策 针对个人版 Copilot 套餐发生了变更。除非用户主动退出，GitHub 现在可以使用 Copilot Free、Pro、Pro+ 和 Max 的交互内容来训练和改进 AI 模型，包括输入、输出、代码片段以及相关上下文。Copilot Business 和 Enterprise 的数据仍受 GitHub 数据保护协议保护。关键在于：这涉及的是 Copilot 交互数据，而不是静静躺在 GitHub 上、根本没被用过的私有仓库。
与此同时，迁移的理由又因另一件事被翻了出来：公开的自托管 Git 实例正在承受大量自动化流量。一场 Hacker News 讨论汇集了运维者关于该问题的一批有价值的记录： 对我来说一个时代结束了：不再自托管 git.
于是留下一个比"选 GitHub 还是自托管"更有用的问题：你真正想解决的到底是哪个顾虑？
简短版本
三个答案。挑出适合你处境的那一个。
- A: 退出但留下。当 Copilot 训练政策变更是你唯一的顾虑，而 GitHub 仍然满足团队运维需求时，选它。关掉账户级别的那个开关，然后继续干活。
- B: 走混合路线。公开的开源项目留在 GitHub 上，以借力网络效应。私有代码迁到自托管的 Forgejo、Gitea 或 GitLab CE 实例，放在 VPN 或 IP 白名单后面。当公开影响力和私有控制权同时重要时，选它。
- C: 彻底迁移。把所有东西都搬离 GitHub。当法规、数据驻留、治理要求或纯自由软件政策排除了 GitHub，且团队能承担运维成本时，选它。
多数读者属于立场 A 或 B。立场 C 的正当理由来自更严格的治理、数据主权或价值观要求，而不是 Copilot 那一个开关。
2026 年 4 月究竟改了什么
技术层面的改动很小。在 Copilot 设置中，个人订阅者可以把"Allow GitHub to use my data for AI model training"设为 Disabled。GitHub 把涉及的内容描述为与其功能和服务的交互，包括输入、输出、代码片段以及相关上下文，而不是从未经过 Copilot 的私有仓库内容。
Copilot Business 和 Enterprise 不显示这个开关，因为它们的数据受 GitHub 数据保护协议保护。对个人套餐来说，关掉这个设置解决的是训练政策这一项顾虑；它并不能化解更根本的反对意见：你依然依赖一项由厂商说了算的政策。
Copilot 的变更可以是导火索，但不等于全部理由。一个团队可能还在意平台依赖、与 GitHub 绑定的身份体系、围绕 Actions 搭起来的工作流、数据驻留，或者以后再搬一次有多容易。这些都属于迁移问题；训练开关不过是其中一个设置。
这个区别很关键：退出只是改了一项数据使用设置，而迁移改变的是谁来掌控托管、身份体系、集成和政策。后一个决定带来的运维成本要高得多。
三种立场详解
把这个决定压缩成三行。细节见下文。
| 你的顾虑 | 答案 | 做什么 |
|---|---|---|
| 我的 Copilot 交互数据被拿去训练 | 退出但留下（立场 A） | 把开关一关，继续干活 |
| 不想放在美国厂商那里的私有代码 + 不想藏起来的活跃开源项目 | 混合（立场 B） | 私有仓库放在 VPN 后面自托管；公开开源项目留在 GitHub |
| 数据主权、受监管行业、坚持纯自由软件、完全摆脱厂商依赖 | 完全迁移（立场 C） | 全部搬走；把运维成本算进预算 |
立场 A：退出但留下
如果你是独立开发者或有私有仓库的小团队，唯一的不满就是训练默认值，那这就是你的答案。改一个开关：一分钟，一次搞定。自托管则意味着：一笔不大的 VPS 账单、一套你真会去演练的备份方案、一堆因为默认走 GitHub 认证而必须重建的集成，以及偶尔在最糟糕的时刻找上门的升级或恢复工作。
自托管仍然可能值得，但前提是这些反复出现的活儿，换回来的是你真正需要的东西。
最有力的反驳是：这个开关本身也是厂商的决定。2026 年，GitHub 从默认不拿这些交互数据训练，改成了默认拿去训练，往后政策同样可以再改。
如果你真正的顾虑是"我永远不想让一家美国厂商单方面决定我的代码怎么处理"，那没有哪个复选框能解决它，立场 A 对你来说就是错的答案。直接跳到立场 C。
但如果你的顾虑恰恰是"我不想让我现在的 Copilot 交互数据进训练集"，并且愿意相信 GitHub 的这个设置直到下一次变动，那立场 A 就是最便宜的正确答案。又便宜又正确，没什么好害臊的。
立场 B：走混合模式
混合托管把公开影响力和私有控制权分开。
分工很简单。公开开源项目留在 GitHub：网络效应、贡献者来源、Dependabot、Actions 生态，这些都是实打实的价值。私有代码搬到自托管实例上，放在 VPN 或 IP 白名单后面，公网永远碰不到。
它之所以奏效，是威胁模型本身的性质决定的。Copilot 训练的顾虑只涉及你经由 GitHub 发出的交互数据。AI 爬虫流量问题（下一节）只涉及公网可达的实例。一套私有的混合方案两头都绕开了。
对 2 到 10 人的私有团队来说，跑 Forgejo 或 Gitea 用 2 vCPU、4 GB 内存是更稳妥的起点；如果搜索索引、软件包或 CI 也挤在同一台机器上，就再多留些余量。这是 Forgejo/Gitea 的配置量级，不是 GitLab CE 的： GitLab 的单节点安装教程 起步就是 8 vCPU、7.2 GB 内存，还没算上 CI 的负载。
别把 Web 界面直接开在 80 或 443 上。在防火墙、代理、VPN 或 mesh 网络这一层加以限制。CI runner 两边都能服务。
选哪个平台，对功能集的影响比混合模式本身还大。Forgejo 和 Gitea 适合更轻量的私有 forge；如果你还需要一体化的 CI/CD 和制品库，GitLab CE 更说得通。
备份是能管好的，但别把它简化成一个 git bundle。 Forgejo 的官方升级指南 把可靠备份定义为对 Forgejo 所用全部存储做的一次同步的时间点快照；在做不到的场合，则用一次 Forgejo dump 搭配单独的 PostgreSQL 或 MySQL dump。无论 Forgejo 还是 Gitea，都要把仓库、数据库、配置、附件和 LFS 数据放在一起备份，异地留一份副本，并且真的演练一次恢复。
开发者本地的克隆能救回代码，但救不回 issue、用户、PR 元数据、附件，也救不回全部 LFS 对象。如果某个私有 fork 以后要转公开，到那时再把它推到 GitHub 镜像上。
立场 C：当控制权是硬性要求时，完全迁移
当摆脱厂商依赖是硬性要求而非个人偏好时，完全迁移最说得通。
有三类人尤其突出：受监管的团队，其审计、数据驻留或厂商管控规定直接排除了 GitHub；公共部门或欧盟的团队，数据主权对他们是政策而非偏好；以及坚持纯自由软件的组织，他们想离开Microsoft 名下的基础设施，而且手里已经有能运维 Linux 服务的人。
代价是一台小 VPS、持续的维护，以及集成的流失。集成流失恰恰是大家会忘掉的那部分。凡是靠 "Sign in with GitHub" 登录的东西，要么继续留在 GitHub 上，要么就得另找一个身份提供方。
迁移规划要围绕依赖来做，而不只是仓库。PR 预览、第三方 Actions、机器人、webhook、软件包注册表，以及 "Sign in with GitHub" 类集成，都可能需要新的凭据、新的流程或替代服务。星标和关注者不会在新 forge 上变成原生记录，所以公开项目还会失去一部分现有的被发现能力。
在切换正式远端之前先做一次演练：迁一个有代表性的仓库，把它的集成重建一遍，验证 issue 和 PR 历史，并把回滚路径写下来。平台之间怎么选，是这次依赖盘点之后的事。
如果团队想要非营利性的治理，又不想自己养一台服务器，Codeberg 值得考虑。
关于数据主权的一点提醒。如果你选自托管是出于欧盟数据驻留的考虑，那机房位置就很重要。法兰克福、阿姆斯特丹这类地点是无聊但正确的选择。弗吉尼亚最便宜的那台 VPS，对你的数据处理协议毫无帮助。
公开 Git 托管的运维成本
公开自托管，等于把一个 forge 暴露在任何面向互联网的应用都会遇到的自动化流量之下，只不过仓库页面还带着 blame 视图、打包下载、提交历史这些开销很大的路径。下面这些报告是个别运维者的经历，不是基准测试。
在前面提到的自托管 Git 讨论里，一位运维者报告称，一个 cgit 实例在 60 天内收到 37,212,377 次请求，其中超过 99% 被判定为机器人。
在同一场讨论中，kstrauser 说他把一个 Forgejo 实例从每天约 600,000 次请求压到了大约 1,000 次，但那是在常规缓解手段之上又叠了一层 JavaScript 加 Cookie 的质询之后才做到的。
其他运维者提到了 fail2ban、GeoIP 封锁、按自治系统整段丢包，以及把仓库搬回托管平台。这些记录展示的是可能出现的失效方式，不是放之四海皆准的流量参考值。
这件事之所以难，机制上的原因是：简单的按 IP 限速，在轮换住宅代理的流量面前可能失效。一支爬虫队列可以把请求摊到足够多的 IP 上，让任何单个地址看起来都不像在滥用，而服务器在总量上照样被压垮。
JavaScript 或 Cookie 质询能挡下不太讲究的爬取，但同样可能把不开 JavaScript 的用户拦在外面，如果对所有路径一刀切，还会干扰走 HTTPS 的 Git 操作。CDN 缓存对重复读取有帮助；对归档包、blame 视图、单条提交页这类唯一或昂贵的端点，帮助就小得多。
质询改变的是这件事的经济账。 Anubis 挡在 forge 前面，要求客户端先完成一道质询，比如一小段工作量证明计算，服务器才会返回受保护的页面，从而抬高大规模抓取的成本。它是缓解手段，不是保证。
浏览器质询要有选择地上。给 Git 操作留着 SSH，并且在给那条路径加防护之前，先测一遍走 HTTPS 的 Git：返回给 Git 客户端的质询页面，换来的是一次失败的 clone，而不是一次有用的验证。
GitHub 把这一类流量当作托管服务的一部分自己扛下来了。一个公开的 Forgejo 或 cgit 实例，则把容量规划、滥用管控、缓存和缓解措施统统留给你。迁移决策里真正重要的，是这份运维责任的转移，而不是软件本身的价钱。
这正是混合模式属于一等选项、而不是退而求其次的原因。私有代码在 VPN 后面：爬虫够不着。公开开源项目在 GitHub 上：机器人流量由 GitHub 的反滥用设施来扛。
如果你还是想要一个公开的自托管 forge，那就把日志、限速控制、缓存、机器人对抗、监控，以及一条不依赖浏览器质询、经过验证的 Git 流量通道，都算进预算里。把防爬当成日常运维的一部分，而不是边缘情况。
开源维护者要面对的网络效应问题
这一节我说的是很具体的一类读者：你在维护一个开源项目。二十位贡献者、两百个星标，还有一个活跃的 issue 区。而你正在考虑把它迁出 GitHub。
对自己诚实一点，看清你换掉的是什么：被贡献者发现的机会、github.com 自带的那层信任背书、Dependabot、CodeQL，以及依附于 GitHub 认证的第三方生态。这些在别处都不是做不到，但每一样都会变成阻力。
我给的经验法则是：如果你的项目价值主要在代码本身，那自托管更好交代。
代码是带得走的。但如果它的价值很大程度上依赖贡献者、issue、搜索可见度，以及围绕 github.com 的那份信任，那么离开就是拿一部分让项目跑得起来的东西，去换维护者心里舒坦一点。理由够大，这笔交换是正当的；只是为了表个态，那就是笔亏本买卖。
Codeberg 的平台介绍 介绍了一个基于 Forgejo、由非营利组织 Codeberg e.V. 运营的服务。对开源维护者来说，这意味着拿到社区治理，却不必背上自己运维 forge 的负担。
对于亲近开源、想要社区治理又不想背升级义务的团队，这一步的运维跨度比自己跑一个公开 forge 要小。SourceHut 则是一次刻意得多的工作流改变，需要单独评估。
做能解决问题的最小改动
在切换远端之前，先用一句话把需求写下来：停止用 Copilot 交互数据训练、把公开托管和私有托管分开，或者把 GitHub 从架构里拿掉。如果你说不出这个需求是什么，那就先别迁。
要迁移，就先拿一个有代表性的仓库做试点。在切换正式远端之前，把认证、Actions、webhook、包发布、预览环境、issue 历史、LFS 数据和回滚步骤都盘点一遍。
Cloudzy's 一键部署 Forgejo 是快速搭起混合模式中私有那一半的办法；在任意 Linux VPS 上手动安装同样可行。无论走哪条路，都要把 Web 界面留在私有范围内，备份完整的应用状态，并在搬迁关键仓库之前先演练一次恢复。
在拥有 root 权限、NVMe 与 AMD EPYC 强大性能的 Linux VPS 上构建应用。
查看 Linux 套餐只有当控制权真的解决了那个需求，而且运维成本是团队长期扛得住的，它才有意义。
常见问题
该因为 Copilot 的训练政策变更而迁出 GitHub 吗？
不是自动就该迁。如果你唯一的顾虑是 Copilot 交互数据被拿去训练模型，那关掉账户级设置就是最小的正确修法。只有当你还需要更强的数据驻留、治理、厂商独立或纯自由软件方面的管控时，迁移才说得通。
GitHub 会拿我所有的私有仓库去训练吗？
不会。本文讨论的政策变更覆盖的是符合条件的 Copilot 交互数据，包括经由 Copilot 发送的输入、输出、代码片段和相关上下文。这并不意味着存在 GitHub 上的每一个私有仓库都会被自动拿去训练模型。
自托管 Git 就一定更私密吗？
只有当你真按那个方式去运维时才是。放在 VPN 或 IP 白名单后面的私有 forge 确实能减少暴露面，但一个公网可达的实例会把打补丁、监控、反机器人、访问控制和备份这些责任加到你头上，而这些平时是 GitHub 替你扛的。
自托管 Git 平台该选哪个？
想要更轻量的私有 forge，就选 Forgejo 或 Gitea。如果一体化的 CI/CD 加上软件包或容器镜像库重要到值得为更高的资源和维护开销买单，那就选 GitLab CE。
小团队跑 Forgejo 或 Gitea，需要多大的 VPS？
两到十人的私有团队，2 vCPU、4 GB 内存是更稳妥的起点。当搜索索引、软件包、大仓库或 CI runner 挤在同一台机器上时，就加配置。GitLab CE 要单独算，因为它需要的资源更多。
切换正式远端之前，应该先测什么？
先拿一个有代表性的仓库做试点。在整体搬迁之前，逐项验证 issue 与 PR 历史、认证、Actions 或替代的 CI 流程、webhook、包发布、LFS 数据、预览环境、备份、恢复，以及回滚路径。
