GitHub回应中国无法访问故障为意外 一次提交更新两个仓库

昨天（4 月 13 日）下午，国内的开发者圈子里炸开了锅！大量朋友发现，在未登录状态下访问全球最大的代码托管平台 GitHub 官网时，页面竟然显示 “Access to this site has been restricted.”（访问此站点受到限制）。

这可急坏了不少人！GitHub 对于开发者来说，那可是日常工作学习离不开的“粮仓”啊！一时间，“GitHub 是不是被墙了？”的疑问和焦虑迅速蔓延。

当时的情况是这样的：

• 选择性“失联”： 已经登录了 GitHub 账号的用户，似乎还能访问部分功能，但如果你没登录，或者想打开 GitHub 首页，那就彻底没戏了。
• 地域性差异？ 有些地方的朋友反映还能断断续续访问，但网络丢包率非常高，访问极其不稳定。这让人猜测是不是某些地区的网络策略有所调整。
• 官方沉默： 最开始 GitHub 并没有立刻发布官方声明，这更增加了大家的疑虑。

官方终于回应：是配置失误，已撤回！

好在，到了 4 月 13 日晚上，GitHub 在他们的官方事故状态页面（githubstatus.com）终于对此事做出了回应。简单来说，这是一次技术乌龙！

GitHub 的官方公告是这么说的（搬主题给大家翻译提炼一下）：

【未登录用户从中国的访问暂时受阻】

由于我们进行了一次配置更改，意外地导致了未登录用户在尝试从中国访问 GitHub.com 时暂时无法访问。已经登录的用户则不受影响。

这个影响从 2025 年 4 月 12 日 20:01 (UTC) 开始。
到 2025 年 4 月 13 日 14:55 (UTC) 问题已经得到缓解。

导致这个问题的配置更改已经被撤回了。现在用户访问 GitHub.com 应该不会再遇到问题了。

（公告原文链接：https://www.githubstatus.com/incidents/jfvgcls9swln）

虚惊一场？但警钟必须敲响！

虽然这次 GitHub 在中国的访问故障最终被证实是技术失误导致的“乌龙事件”，但这次“惊魂记”也实实在在地提醒了我们每一个人：过度依赖任何单一的、尤其是国外的平台，都潜藏着巨大的风险！

想象一下，如果这次不是技术失误，而是其他更复杂的原因导致访问受限，那对国内的开发者和依赖 GitHub 的项目来说，影响将是灾难性的。

对咱们中国开发者来说，这事儿之后，有几点应对策略值得认真考虑：

1. 多平台备份，鸡蛋不放一个篮子： 重要项目，是不是可以考虑同时在 GitHub 和国内的 Gitee（码云）等平台都维护一份？至少关键代码得有个双重备份，心里才踏实。
2. 离线备份是王道： 定期把重要的代码库整个导出，存到本地硬盘、NAS 或者其他可靠的存储介质上。这才是最保险的底线。
3. 关键依赖本地化： 项目里依赖的那些重要的开源库，是不是可以考虑在国内或者本地搭建镜像（Mirror）？这样就算源头访问不了，项目构建也不会“卡脖子”。
4. 拥抱国内开源社区： 积极参与和建设国内的开源社区和平台，构建咱们自己的技术生态圈，这不仅是备份，更是长远发展之计。
5. 提升自身技术内功： 不能只停留在“用工具”的层面，要深入理解核心原理，不断积累和深化自己的技术能力，这才是应对一切变化的根本。

技术无国界，但现实有壁垒

这次事件虽然是误会，但也折射出一个现实：技术的交流与合作并非总是一帆风顺。开源精神鼓励开放共享，但地缘政治、网络环境等因素都可能带来意想不到的阻碍。

正如一位资深技术专家所说：“开源不是单向的接受，而是双向的贡献。中国开发者应当在使用开源的同时，也积极回馈社区，同时构建自己的技术体系。”

搬主题看法：

这次 GitHub 的“乌龙事件”确实让大家捏了一把汗。虽然官方及时修复并澄清了，但由此引发的关于“技术安全”和“平台依赖”的讨论非常有必要。对于国内开发者和企业来说，建立风险意识，采取多元化的策略，加强自主可控的能力，将是未来需要持续思考和投入的方向。

一次提交更新两个仓库教程

现在很多开发者都不满足于只在一个代码托管平台活跃，将项目同时托管于 Gitee 和 GitHub 是目前国内很多开发者的选择，既拥有更快的访问和代码推拉速度，也可以和更多国际上的优秀开发者交流。

Gitee 的仓库镜像管理功能在这两天重新受到了开发者们的关注，今天马建仓再次为大家介绍一下这个超方便的功能，方便各位开发者更优雅地将代码在世界上最大的两个代码托管平台之间同步。

什么是仓库镜像管理

仓库镜像管理功能用于配置和管理仓库镜像；配置仓库镜像可以实现不同平台之间仓库分支、标签和提交信息的自动同步。

简单来说，就是你可以通过仓库镜像管理功能实现 Gitee 和 GitHub 两个平台的双向自动同步。

• 将 Gitee 的仓库镜像至 GitHub

配置此镜像后，当你提交代码到 Gitee 的仓库时，Gitee 会自动向 GitHub 同步仓库。

• 将 GitHub 的仓库镜像至 Gitee

你可以根据自身需求选择自动镜像或手动镜像。

自动镜像：当你提交代码到 GitHub 镜像仓库时，Gitee 会自动从 GitHub 同步仓库。

手动镜像：只有你手动点击更新按键时，Gitee 才会从 GitHub 同步仓库。

仓库镜像会同步以下内容：

• 分支（Branches）
• 标签（Tags）
• 提交记录（Commits）

如何为自己的仓库设置镜像

以将 GitHub 的仓库镜像至 Gitee 为例

进入需要使用镜像功能的仓库，进入「管理」找到「仓库镜像管理」选项，点击「添加镜像」按钮，如果你还没有绑定 GitHub 帐号，请根据弹窗提示绑定 GitHub 帐号；

添加镜像

• 在「镜像方向」中选择 Pull 方向；
• 在「镜像仓库」下拉列表中选择需要镜像的仓库；
• 在「私人令牌」中输入你的 GitHub 私人令牌；

私人令牌中必须包含对 repo 的访问授权，否则添加后镜像不可用。

• 根据自身需求选择是否勾选「自动从 GitHub 同步仓库」

勾选后，将会在镜像仓库中自动生成 webhook 用于实现自动镜像。此功能需要你的个人令牌中包含对 admin:repo_hook 的访问授权，否则会添加失败。

• 点击「添加」保存镜像配置。

配置完成后，可以通过提交代码到 Gitee 仓库或手动更新镜像的方式触发镜像操作。

一次提交，同步两个仓库，更优雅的仓库镜像姿势你 Get 到了吗？

点击后面的链接了解更多功能细节：https://gitee.com/help/articles/4336

注意事项

• 镜像触发的最短间隔时间为 5 分钟；
• 只支持镜像已绑定 GitHub 帐号授权访问的仓库；
• 更新请求一旦发出，除非强制停止，否则将无法中断；
• 暂时不支持同步 Git-LFS；
• 同步时间超过 30 分钟视为超时，大型仓库不建议使用镜像方式同步；
• 镜像操作会覆盖目标仓库的分支、标签和提交记录；请注意备份并小心使用。

单向导入同样支持

同时 Gitee 也支持从 GitHub 单向导入仓库的操作。

点击右上角 + 后选择从 GitHub/GitLab 导入仓库，连接自己的 GitHub 账号即可实现仓库的一键导入。

欢迎使用 Gitee：https://gitee.com/