GitHub Codespaces 入门

本文将为您迅速梳理使用 GitHub Codespaces 所需的全部要点。值得学习它，因为它通过提供即时、基于云的开发环境，正在改变开发者的工作方式。我们将梳理 GitHub Codespaces 的生命周期，帮助您理解其中的不同阶段；另外，我们还会介绍如何自定义您的 codespace，使其符合您的工作风格与需求。

如果您对 Git 和 GitHub 还不熟悉，也不必担心。您可以学习我们的 GitHub 概念 课程，了解如何创建仓库、README 以及许多基础内容。同时，不妨学习我们的 Git 基础 课程，从版本控制的基本知识入手。

什么是 GitHub Codespace？

GitHub Codespace 是一种基于云的开发环境，允许开发者直接在云端编写、测试和调试代码，从而免去复杂的本地环境配置。创建 codespace 时，它会在一台虚拟机上启动一个 Docker 容器，其中预先配置了项目所需的工具、库和依赖。GitHub Codespaces 的一项显著特性是可与 Visual Studio Code 等 IDE 集成，本文后面将进一步介绍。

Codespace 工作流。来源：GitHub

理解 GitHub Codespaces 的生命周期

要理解 GitHub Codespaces，需要先理解一个 codespace 的生命周期。每个阶段都会涉及特定操作，影响您的使用体验或资源使用方式。

创建阶段

创建 codespace 时，主要有两种选择：基于现有项目启动，或新建项目。如果您在处理现有项目，通常会从已有的仓库分支创建 codespace，并且该 codespace 会与您选择的特定分支关联。如果要启动新项目，也可以使用模板。模板很实用，因为它提供预配置环境，帮助您快速开始。

需要说明的是，虽然模板主要用于新项目，但如果您在处理现有项目且希望使用某个模板中的特定设置，也可以应用该模板的配置来优化环境，这也是一种可选方案。

在 GitHub 菜单中找到 Codespaces。图片作者自制

按设计，与 Git 和分支的交互流程与在本地机器上的工作流类似。在两种情况下，您都会将项目发布到 GitHub 仓库，并需要确保将更改推送到 GitHub。

重建阶段

创建新的 codespace 是重建 codespace 的一种替代选择。但在某些情况下，重建 codespace 更有优势，了解差异很有必要。首先，重建可以在不丢失 /workspaces 目录中任何工作的前提下，应用容器配置的更新。此外，重建时 GitHub Codespaces 会复用此前构建的缓存镜像，避免重复安装库，从而加快过程。

重建容器。图片作者自制

停止阶段

我们之所以停止一个 codespace，是因为在环境暂停时不消耗资源，有助于控制成本。请记住，运行中的 codespace 会产生 CPU 费用，而已停止的 codespace 只产生存储费用。

重要的是，如果您未明确停止 codespace，它会一直运行，直到因不活跃而超时。超时时长可自定义，下一节会介绍。另外，仅关闭浏览器标签页并不会停止 codespace 本身。这是人们常犯的错误。

停止 codespace。图片作者自制

删除阶段

完成项目后，请删除 codespace，避免产生不必要的存储费用。保持工作区整洁也是良好习惯。

您可以在删除前将更改推送到远程分支，或直接丢弃所有未提交的更改。此外，长时间不活跃的 codespace 会被自动删除。这样设计是为了帮助开发者管理存储和成本。自动删除前的保留时长也是一个可自定义项，稍后会介绍。

删除 codespace。图片作者自制

自定义 GitHub Codespaces

GitHub Codespaces 的一大优点是高度可定制。您可以选择某种配置或特定工具。总体而言，可分为两类：一类是为了贴合您的工作风格而进行的个性化设置，另一类是为了管理资源、降低成本的设置。

个性化您的 codespace 环境

首先可以考虑如何进行个性化设置。开发者通常会欣赏能契合其特定工作流的自定义项。大多数此类设置可通过点击您的个人头像打开设置菜单来访问，如下图所示。

打开设置菜单。图片作者自制

设置同步（Settings Sync）

您可能首先希望确保桌面版 VS Code 与网页版客户端的设置保持一致。启用设置同步后，您在任一端的更改或自定义都会同步应用到另一端。对于需要在不同环境间切换的开发者来说，这一功能非常便利。

启用设置同步。图片作者自制

若云端设置与本地设置存在差异，或某台机器长时间离线，可能会出现冲突。发生冲突时，您可以选择用本地或云端设置覆盖，或更细致地选择保留哪些设置。

重命名 codespace

GitHub 会为每个新建的 codespace 分配一个显示名称。通常不建议保留自动生成的名称，尤其在您同时使用多个 codespace 时。我会尽量取一个能体现项目目的、便于快速识别的名字。

重命名 codespace。图片作者自制

需要了解的是，除了显示名称，每个 codespace 还有一个不可更改的永久名称。这个永久名称其实是在显示名称末尾追加了一串随机生成的字符。设置永久名称的目的是确保 codespace 具有唯一标识。如果您计划使用 GitHub 命令行接口，请特别注意这个永久名称；如需联系 GitHub 支持团队，它也很有用。您可以在浏览器中打开该 codespace，浏览器子域名即为永久名称。

更换 Shell

如果您在 VS Code 桌面应用中打开新的 codespace，启动的 Shell 取决于本地设置；在 VS Code 网页客户端中，默认会打开 bash。您可以随时更换为 zsh 或 fish 等您偏好的 Shell，并在设置中应用该更改，使每次都默认打开您喜欢的 Shell。

更换 Shell。图片作者自制

设置默认编辑器

您也可以选择自己偏好的代码编辑器。例如，如果您和我一样喜欢 Visual Studio Code，可以在设置中配置为每次创建或打开 codespace 时都启动 VS Code。可选项包括 VS Code、JetBrains 和 JupyterLab。

选择默认编辑器。图片作者自制

管理资源与性能

下面来看与资源分配和性能相关的设置。

更改机器类型

您可以选择或修改为环境提供算力的底层硬件。例如，可切换到拥有更多 CPU、内存或存储的机器。这样既能确保 codespace 有足够资源处理当前任务，也能避免资源过度配置。请留意所用远程机器类型，因为不同类型对应不同计费档位。

选择偏好的机器类型。图片作者自制

请注意，只有已发布的 codespace 才能更改机器类型；因此，如果您是从未关联 GitHub 仓库的模板创建的 codespace，将无法更改机器类型。另如您属于某个组织，是否可更改机器类型还取决于您所受策略的限制。

自定义超时时长

默认情况下，GitHub Codespaces 会在 30 分钟后自动停止运行，您可以在个人设置中进行调整。最大超时时长为 4 小时。请关注资源使用，避免无必要的空闲 codespace 持续运行。

更改超时时长。图片作者自制

配置自动删除

非活跃的 codespace 会在一段时间后被删除。此举旨在便捷地释放资源。您可以配置停止的 codespace 在被删除前的保留时长，但请注意最长保留期为 30 天。

设置保留期。图片作者自制

选择地理区域

您可以在个人资料设置中为 GitHub Codespaces 设置默认托管的地理区域。选择更接近您位置的区域可提升性能，如更快的加载速度与更低的延迟；同时也便于根据数据属地要求来定制数据存储位置。

更改区域。图片作者自制

GitHub.dev 与 GitHub Codespaces 的区别

如果您熟悉 GitHub，可能也听说过 GitHub.dev，并会好奇它与 GitHub Codespaces 有何不同。

简而言之，GitHub.dev 是一款轻量级、基于浏览器的代码编辑器；而 GitHub Codespaces 提供的是完整的开发环境，您可以运行和测试代码。换句话说，由于 GitHub.dev 的功能范围有限，它主要用于快速编辑代码。

GitHub Codespaces 还可与 VS Code 等 IDE 集成，且云端与本地环境中的设置更改可通过设置同步功能进行同步，如前文所述。开发者还会注意到，GitHub.dev 环境不是持久性的，除非您手动将更改提交到仓库，否则不同会话之间不会保留工作内容。反之，在 GitHub Codespaces 中，即使您关闭或停止了 codespace，更改也会被保存。

综合来看，对于更大的项目和更复杂的工作流，GitHub Codespaces 更合适，因为它无需在个人机器上进行配置或资源管理，却能提供完整开发环境的能力。

随着工作形态向分布式与灵活化发展，GitHub Codespaces 等工具将在塑造软件开发的未来中发挥重要作用。具体而言，GitHub Codespaces 解决了几大问题：无论本地机器配置如何，都能立即开始编码；可在任何设备上访问开发环境；并能在一致的环境中与团队成员协作。

若想进一步学习，请阅读以下 DataCamp 文章：

• 数据专业人士的 GitHub 认证指南
• 理解 GitHub：什么是 GitHub 以及如何使用
• GitHub Actions 与 MakeFile：实践入门

最后，欢迎收听 DataCamp 播客节目 与 GitHub 首席运营官 Kyle Daigle 探讨编程的未来，其中他分享了对 AI 辅助编程现状及行业发展方向的看法。