Codespaces：新保留期管不到旧工作空间

摘要

把保留期从三十天改成七天，听起来像一次利落的清仓。对于 GitHub Codespaces，这个动作更像给新租客换了合同，老租客仍住在原来的条款里。

这是假设的设置调整，规则却很具体。GitHub 的组织保留期文档规定，期限在工作空间创建时分配。修改策略，旧空间的期限不变；删除策略，旧空间的期限也不变。管理界面可以在一刻之间变得节俭，存量环境需要另算。

对想压低开发成本的公司，这个差别颇有喜剧效果：最容易拿来展示的省钱动作，恰好没有替最需要清理的旧环境办理退房。

Codespaces 把开发环境放在云端。停止运行后，开发者可以回来继续工作，原先保存的文件还在。这个便利有明确的用量后果：GitHub 的生命周期说明区分运行中的计算与存储；停止后仍产生存储用量，直到空间被删除。已经累计的当月用量，也不会随删除动作被抹掉。

于是，财务看到的最新政策与机器实际遵守的期限，可能属于两个年代。假设组织过去采用三十天，如今改成七天，原来按三十天创建的空间仍按原期限保留；新建空间再按适用规则取得自己的期限。审核一张新设置截图，无法知道旧空间何时退出。

规则的边界还落在付款人身上。组织保留策略适用于组织付费的工作空间。代码仓库归组织，并不自动把开发者个人付费的空间纳入同一策略。适用的组织、仓库和个人期限中，较短的期限决定新空间的保留安排。管理者若只按仓库名称拉一张清单，连自己能管哪些空间都可能算错。

这里的成本问题无需一张惊人的账单来成立。一个停着的工作空间，仍占着可以留给别的工作的存储资源。究竟带来多少额外现金支出，要看实际用量与账户安排。公开文档没有客户的空间清单、分配期限、未推送改动和账单，无法据此计算实际节省或损失。

开发者说“我保存过了”，管理员说“可以删了”，两句话之间可能隔着一份只活在云端工作空间里的改动。

保存文件把内容留在虚拟机上。提交并推送到远程仓库，才完成另一件事。GitHub 的自动删除说明明确写明，删除会照常进行，即使存在未推送的改动。计时器没有兼职做代码保管员。

默认安排是停止且闲置三十天后删除，个人设置可以采用零至三十天的期限。再次连接会重置计时，停止后重新起算。因此，“创建很久”与“即将到期”也不能互相代替。有人偶尔回来看看，就可能让一个空间继续留下来；新建空间如果被分配了更短期限，反而先走。

零天尤其容易被当成成本纪律的漂亮答案。它让空间在停止或因闲置超时停止时立即删除，等于把“稍后回来继续”这项便利一并撤掉。关掉浏览器标签本身又不会让远端空间停止。使用者的直觉与系统状态，需要在真正的停止、推送和删除动作上对齐。

个人符合条件的空间可以选择保留，持续占用存储，直到手动删除；受组织保留策略约束的组织空间没有这项保留选项。公司买到的控制范围与个人拥有的例外，不能混成一句“所有环境最多留三十天”。

GitHub 提供了导出改动到分支的路径，无需先启动空间。这对遇到支出限制、不能重新打开环境的人很有用。但出口有尺寸：它处理当前检出的分支，其他分支不会一同导出；大于 100 MiB 的文件会阻碍相关推送和导出。

这意味着“点过导出”与“重要工作已经在仓库里”之间，仍有一次核验。使用者需要看得到目标分支里的内容，知道其他分支是否有独有改动，也知道环境本身能否重新搭建。一个分支可以承载代码，却不会自动替公司搬走整张工作台。

清理顺序因而很朴素：找出旧空间，确认真正适用的期限和付款人，把有价值的工作带走，再决定是否继续租这份随时可重启的便利。新策略负责今后的入口，存量清理负责眼前的房间。省钱真正发生的地方，是那些已经作出决定并执行退场的空间。