引言#
这是一份关于“如何保存一个 GitHub 仓库”的决策指南。实现这一目标有很多不同的方法，它们在投入的精力、技术难度、可持续时间长度以及可靠性方面都有所不同。下面的指南主要概述三种用来保存托管在 github.com 上源代码的主要方法。
为什么要保存源代码？
软件已经成为当代社会不可或缺的一部分，承载了我们大量的文化知识。然而，正如 Di Cosmo 和 Zacchiroli（2017）所说，与其他形式的数字保存相比，源代码在数字档案生态中还没有真正获得“第一等公民”的地位。
为什么软件处于风险之中？
内在的易废性 软件依赖特定的运行环境、编程语言和各种依赖项。这些条件不断变化，而目前也没有一个统一的数据模型可以涵盖所有版本控制系统。
项目被放弃 如果一个项目缺乏持续维护，与该软件相关的知识有可能永久丢失。
审查与删除 即便软件可以在不同平台之间迁移，代码托管平台仍有可能因为政策违规或政治压力而删除相关内容。
平台依赖 大多数代码托管平台并不对“长期保存”做出任何保证。2015–2016 年 Gitorious 和 Google Code 的关闭就很典型：在很短的时间内，超过 150 万个项目被迫迁移到其他地方。
当前的软件保存现状
目前有两个主要计划代表了软件保存的不同路径。
GitHub Arctic Code Vault Arctic Code Vault 采取了一种更加聚焦的方式来创建长期的物理备份。这个计划会对公共仓库做快照，并将它们存储在斯瓦尔巴群岛（Svalbard）一座退役的煤矿中，这个地点是因为地质条件稳定而被选中。然而，Arctic Code Vault 主要关注的是对仓库进行快照，而不是完整捕捉开发历史及其演变过程。因此，它本质上更接近于“灾难恢复备份”，而不是一个主动维护的档案系统。
Software Heritage
Software Heritage 则采取了一种根本不同的方式，它更强调广泛可访问性和长期可行性。它并不依赖单一备份地点，而是维护着一个由多个“镜像站”组成的地理网络，并坚持“无事先选择”的原则，尽可能全面地归档源代码。截止 2022 年 6 月，Software Heritage 已经归档了超过 1.8 亿个软件起源，收录了超过 120 亿个独特的源代码文件，使其成为目前世界上规模最大的源代码合集。
一个 GitHub 仓库由哪些部分组成？
理解一个完整的 GitHub 仓库由哪些部分组成，有助于我们思考：哪些元素是“核心的”，哪些则可以被视为“次要内容”。
核心技术文献
- Source code（源代码）：仓库中最主要的对象。
- Commit history（提交历史）：记录对文件所做的更改。
- Branch（分支）：用来在不影响主分支的前提下进行新修改的独立工作空间。
- Tag（标签）：指向项目历史中某个特定提交（commit）的标记。
- README：对项目的概述性说明文档。
- License（许可证）：关于使用与分发方式的法律声明。
记录这些元素，可以在某个时间点上形成对仓库的一个“全面快照”。就像磁盘镜像一样，这些内容在特定时刻反映了一个数字卷的具体内容和功能。从保存的角度来看，这种做法可以被视为最低可行的保存努力：它捕捉到了足够的细节，使未来的使用者能够理解并有可能在此基础上继续构建。对于一些从未拥有过大型社群参与的软件，这样的保存水平也许已经足够。
协作内容与次要组件
然而，当代软件开发越来越强调协作过程。保存这些“次要内容”，可以让我们更好地把仓库看作一个“社群成果”：例如，通过它们来观察社群内部是如何围绕技术方案进行讨论与决策的。不过，这些内容高度动态化，也会给保存工作带来新的挑战。
- Issue 与 Pull Request：用于错误报告、功能请求以及提出代码修改方案。
- Wiki page：篇幅更长的说明与文档。
- Project：GitHub 中用来规划和追踪工作的工具。
- Release：面向分发的软件版本，通常带有发布说明。
- Actions：支持持续集成 / 持续交付（CI/CD）的自动化工作流程平台。
- Discussions：用于更开放的协作讨论的交流空间。
元数据与相关材料的问题
在软件保存与归档工作中，关于元数据与相关材料的问题是一个关键议题。针对与源代码相关的附加材料，不同的保存方式会采用不同的保留与标记策略，而这些策略的差异，往往会显著影响不同保存实践之间的区别。例如：
- 有的做法只关注源代码本身；
- 有的做法则会同时保存文档、图片、论文、运行说明、构建脚本等一整套材料，并精细地标注它们与源代码之间的关系。
在后续章节中，不同的保存路径（本地方案、Software Heritage、机构方案等）也会在“如何处理这些相关材料”这个问题上呈现出各自的特点。