跳至主要内容

GitHub Codespaces 的灾难恢复

本文介绍了灾难恢复场景的指导,当整个区域因重大自然灾害或广泛的服务中断而停电时。

我们努力确保 GitHub Codespaces 始终可用。但是,有时超出我们控制的力量会以可能导致意外服务中断的方式影响服务。

虽然灾难恢复场景很少发生,但我们建议您为整个区域发生中断的可能性做好准备。如果整个区域遇到服务中断,则您数据的本地冗余副本将暂时不可用。

以下指南提供了有关如何处理部署了您的代码空间的整个区域的服务中断的选项。

注意:您可以通过频繁推送到远程存储库来减少服务范围中断的潜在影响。

选项 1:在另一个区域创建新的代码空间

在区域中断的情况下,我们建议您在未受影响的区域重新创建您的代码空间以继续工作。此新代码空间将包含您上次推送到 GitHub 时的所有更改。有关手动设置另一个区域的信息,请参阅“设置 GitHub Codespaces 的默认区域”。

您可以通过在项目的存储库中配置 devcontainer.json 来优化恢复时间,这使您能够定义自动恢复开发环境所需的工具、运行时、框架、编辑器设置、扩展和其他配置。有关更多信息,请参阅“Dev 容器简介”。

选项 2:等待恢复

在这种情况下,无需您采取任何操作。请知悉,我们正在努力恢复服务可用性。

您可以在 状态仪表盘 上查看当前服务状态。

选项 3:在本地克隆存储库或在浏览器中编辑

虽然 GitHub Codespaces 提供了预先配置的开发者环境的优势,但你的源代码始终应该可以通过托管在 GitHub.com 上的存储库访问。在 GitHub Codespaces 中断的情况下,你仍然可以在本地克隆存储库或在 GitHub 浏览器编辑器中编辑文件。有关详细信息,请参阅“编辑文件”。

虽然此选项不会为你配置开发环境,但它将允许你在等待服务中断解决时根据需要对源代码进行更改。

选项 4:使用 Dev Containers 扩展和 Docker 作为本地容器化环境

如果你的存储库有 devcontainer.json,请考虑在 Visual Studio Code 中使用 Dev Containers 扩展 来构建并连接到存储库的本地开发容器。此选项的设置时间将根据你的本地规范和 dev 容器设置的复杂性而有所不同。有关详细信息,请参阅 VS Code 文档中的“在容器内开发”。

注意:在尝试此选项之前,请确保你的本地设置符合 最低要求