摘要

  • GitHub 将归档说明为令仓库对所有用户只读、并表示项目不再被积极维护的状态；仓库也可以解除归档。
  • 该状态描述的是 GitHub 上的仓库表面，而不是某个组织实际运行的包、版本或制品。
  • 归档观察与下游依赖的保留、替换、隔离或退役决定，应当保存为两条可归因的记录。

一个清楚但范围有限的平台状态

归档标签很容易被读成终局。它出现在仓库名称旁，而代码、发行版、标签、议题和历史仍然可见。于是“该依赖已经结束”显得像一个省事的结论。但这个句子把 GitHub 所记录的对象，与另一组织可能使用的对象混为一谈。

GitHub 的仓库归档说明给出的边界更准确：归档使仓库对所有用户只读，并表示项目不再被积极维护。议题、拉取请求、代码、标签、里程碑、项目、wiki、发行版、提交、分支、反应、代码扫描警报、评论和权限都会成为只读；若要修改，仓库必须先解除归档。

这是一项有价值的可验证观察。它可以说明某一时点、某一仓库在 GitHub 的可写表面以及维护姿态。它不能说明某个消费者解析了哪个版本、某个二进制是否还在生产环境、内部镜像是否改变、某次例外是否仍有效，或谁承担了后续选择。归档也不是删除：GitHub 还说明可以解除归档。把可逆的仓库状态叙述成不可逆的依赖结论，反而会使原本清晰的信号失真。

决定所面对的不是仓库页面

使用者面对的可能是注册表包、固定提交、私有重构制品、嵌入式副本、间接依赖或容器镜像。对每一项，决定需要的事实不同：实际解析的版本或摘要、使用环境、权限和数据暴露、可替代来源、责任人以及复核日期。这些事实不在归档标记中。

因此，归档可作为触发器，而不是处置结果。团队可能发现该仓库与自身任何已部署资产都没有对应关系；可能安排迁移；可能记录有限使用及其到期条件；也可能先监测而尚未作出结论。把所有触发器自动改写成“已退役”，会同时抹去实际决定和尚未解决的不确定性。

GitHub 对其他平台动作也保持区分。转移仓库改变的是由谁管理仓库；改变可见性对 fork、访问与分析功能有独立后果。它们都是不同控制面，不能彼此代替，更不能替代使用者的资产盘点或风险判断。

让观察与处置各自有记录

第一条记录应当保存精确仓库引用、归档或解除归档状态、观察时间和来源，并明确其证据边界。以后出现解除归档时，应添加新的时间点，而不是悄悄抹掉先前的观察。

第二条记录属于使用者。它要关联实际的包、提交或摘要，写明用途与暴露、审阅过的证据、承担决定的人、所选动作或明确的不动作，以及下次复核的触发条件。这样，公开的归档信号仍然可用，本地承担后果的判断也不会被假装成 GitHub 已经替人作出。

来源

  1. GitHub Docs — Archiving repositories
  2. GitHub Docs — Transferring a repository
  3. GitHub Docs — Setting repository visibility