Github宣布：转移到 Codespaces。
GitHub经过博客告知开发者们，他们将其扩展到GitHub团队和企业（云）方案，末尾更普遍地推出其基于阅读器的编码环境Codespaces。
这家微软旗下的公司还宣布，外部曾经从MacOS形式过渡到Codespaces，后者如今是GitHub的默许开发环境。
GitHub于去年5月初次推出Codespaces，作为具有一切常用GitHub功用的云托管开发环境。
它基本上由微软的Visual Studio Code提供支持，该代码自2019年起作为基于Web的编辑器提供，并于去年更名为Visual Studio Codespaces。
9 月，微软还确认将Visual Studio Codespaces整合到GitHub Codespaces 中。
GitHub的Codespaces最后是在面向团体用户的「有限地下测试版」中推出的，而如今团队或企业（不包括自托管）方案中的一切企业都可以在其 GitHub设置中自动启用Codespaces，并且他们如今可以在一切私有存储库中运用Codespaces。
经过将编码环境带到云端，开发人员可以更轻松地参加和协作项目，并以最少的配置末尾编码。
在这14年中，支持GitHub.com (github/github) 的中心存储库曾经收到了超过一百万次提交。这些提交中的绝大少数来自在 macOS 上构建和测试的开发人员。
将GitHub迁移到Codespaces可以处置开发者环境不同的成绩。
想法有多理想，完成起来就有多困难。
GitHub.com存储库在磁盘上简直占了13GB。
只是复杂地克隆一下存储库，啪，20分钟就过去了。
结合依赖设置，bootstrap一下GitHub.com的代码空间，45分钟过去了。
一旦将存储库成功挂载到代码空间中，运用顺序还不运转了。
14年来，以macOS为中心的想象付之东流。
但坚强的工程团队又怎样会轻言保持！
他们末尾质疑不断以来的想象，并在源代码级别任务以将GitHub开发与macOS别离。
最后，虽然速度很慢，但至少可以在Linux主机上提供可用的GitHub.com代码空间，从Visual Studio Code衔接，交付一些任务。
下面来看看团队是如何完成「闪电般速度」的云端开发环境。
从45min到5min
运用Codespaces的目的是希望可以为手头的义务按需提供开发环境，分支和代码空间之间的映射大致为1:1。
为了支持基于义务的任务流，团队希望可以做到「即开即用」。
团队不满足于45分钟，但是这个时间长度还是能让人看到希望。
首先是要改动Codespaces克隆github/github的方式。
与之前在配置时执行残缺克隆不同，如今Codespaces执行的是浅层克隆。
然后在运用最新提交创立代码空间后，在后台执行非浅层存储库历史记载。
这样克隆时间就能从20分钟延长到90秒！
下一个要改良的，是缓存支持GitHub.com的软件和效劳网络。
包括传统的基于Gemfile的依赖项以及用C、Go和自定义构建的Ruby编写的效劳。
团队提出了一个处置方案，那就是让GitHub Action每天早晨夜深人静的时分悄然运转。
当然是为了克隆存储库，引导依赖项，还有构建和推送结果的Docker image。
发布的image随后被用作github/github的
devcontainer-config-as-code中的基础镜像，构成Codespaces环境。
