跳至主要内容

GitHub Codespaces 灾难恢复

本文介绍了灾难恢复方案的指南,当整个区域因重大自然灾害或广泛的服务中断而发生中断时。

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

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

以下指南提供了有关如何处理 Codespace 部署到的整个区域的服务中断的选项。

注意

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

选项 1:在另一个区域创建新的 Codespace

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

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

选项 2:等待恢复

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

您可以在状态信息中心上查看当前服务状态。

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

虽然 GitHub Codespaces 提供了预配置开发环境的优势,但您的源代码应始终可以通过托管在 GitHub 上的存储库访问。如果 GitHub Codespaces 出现故障,您仍然可以在本地克隆存储库或在 GitHub 浏览器编辑器中编辑文件。有关更多信息,请参阅“编辑文件”。

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

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

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

注意

在尝试此选项之前,请确保您的本地设置满足最低要求