Debian 作为全球最大的开源 Linux 发行版之一，其源代码管理系统的演进一直是技术社区关注的焦点。近期，Debian 项目正式启动了从传统的 Debian Source Package（dsc）系统向 Git 的全面迁移，这一转变不仅涉及技术架构的重构，更关系到整个开发者生态系统的重塑。本文将从工程角度深入分析这一迁移的技术实现、设计决策以及面临的挑战。
迁移背景与核心目标
Debian 的 Git 迁移项目始于一个明确的目标："每个与 Debian 源代码交互的人都应该能够完全在 Git 中进行操作"。这一目标看似简单，实则蕴含了深远的工程意义。传统的 Debian 源包系统基于.dsc文件和相关的 tarball，这种设计在 20 年前是合理的，但在现代版本控制实践面前已显陈旧。
迁移的具体目标包括：所有源代码的检查和编辑都应通过正常的 Git 操作完成；源代码应以 Git 数据而非 tarball 的形式传输和交换；上游 Git 历史应作为正式 Git 发布的一部分可追溯地重新发布；开发者不应再需要学习 Debian 源包这一已被现代版本控制淘汰的复杂概念。
核心工程原则：双向无损转换
迁移项目的核心工程原则是每个 Debian 源包都可以无损地转换为 Git，反之亦然。这一原则确保了迁移过程的平滑性和向后兼容性。为了实现这一目标，项目团队开发了dgit作为双向网关工具。
dgit的关键设计在于定义了一个不变式：与.dsc 对应的规范 Git 树是执行dpkg-source -x命令后得到的结果树。这种规范形式有时被称为 "dgit 视图"，它确保了从 Git 到源包的转换是确定性和可逆的。
这种双向转换机制允许项目在迁移过程中保持双轨运行：使用传统工具如dput上传的源包可以被导入到规范的 Git 表示中；同时，开发者准备的 Git 分支也可以转换为源包，以兼容遗留的下游系统（如 Debian 存档和apt source）。
仓库结构设计：patches-applied vs patches-unapplied
在 Git 仓库结构设计上，Debian 团队做出了一个重要的技术选择：采用 "patches-applied"（补丁已应用）作为规范格式，而不是许多维护者习惯的 "patches-unapplied"（补丁未应用）格式。
这一选择基于几个关键考虑。首先，patches-applied 格式对 Debian 外部人员更加友好和直观。正如项目文档中指出的，"Debian 内部人员严重低估了 'patches-unapplied' 的怪异程度，即使是经验丰富的软件开发人员也可能感到非常困惑，甚至可能意外构建没有安全补丁的二进制文件！"
其次，patches-applied 格式允许开发者使用正常的 Git 命令进行更改，例如git commit。许多使用 patches-unapplied 的 Debian 内部人员仍在使quilt(1)，这是一个用于处理补丁文件的复杂工具。使用 patches-applied 格式，开发者可以在开发过程中同时修改上游代码和 Debian 打包，无需在补丁队列和打包分支之间来回切换。
然而，这一选择也带来了转换成本。由于许多维护者使用 patches-unapplied 格式，这意味着许多软件包需要将其 Git 表示进行转换。用户和外部人员从{browse,git}.dgit.d.o和dgit clone获取的分支并不总是与 Salsa 上的维护者分支兼容。用户贡献的更改需要进行 cherry-picking 而不是合并，或者转换回维护者格式。
正式 Git 存储库：*.dgit.debian.org 的设计
Debian 团队建立了一个专门的 Git 存储库系统*.dgit.debian.org，而不是依赖现有的 Git 托管平台如 Salsa。这一设计决策基于几个重要的工程考虑。
*.dgit.debian.org被设计为一个 Git存储库—— 一个正式、可靠且永久的已发布 Debian 源代码 Git 仓库。与 GitLab 等 Git 托管平台不同，这个存储库缺乏合并请求等协作功能，但提供了关键的特性：可靠性、安全性、仅追加性（一旦推送就永久记录）、与 Debian 存档相同的访问控制、标准化的引用命名空间（对应 Debian 发布），以及基于 PGP 签名而非 SSH 密钥的可追溯推送授权。
项目文档明确指出："GitLab 不够安全，bug 太多，不能作为我们所有源代码的主要和唯一存档。" 这种设计确保了 Debian 源代码的长期可访问性和完整性。
工作流适配：tag2upload 系统
为了促进 Git 优先的工作流，Debian 团队开发了tag2upload系统。这个系统允许维护者通过推送签名标签来发布软件包，完全避免了传统dput流程中涉及的 tarball 处理。
tag2upload的工作原理是：维护者在本地 Git 仓库中准备更改，创建一个包含标准化元数据的签名标签，然后将该标签推送到tag2upload.debian.org。系统会自动验证标签，构建源包，并将其上传到 Debian 存档。整个过程完全基于 Git，提供了比传统工具更好的用户体验。
重要的是要理解，dgit push和tag2upload并不是gbp pq或quilt的替代品。这些上传工具补充了现有的 Git 工作流，它们替代并改进了源包构建 / 签名以及后续的dput。如果维护者使用 Salsa 上常见的 Git 布局之一，并且软件包状态良好，他们可以立即采用tag2upload和 / 或dgit push。
大规模协作挑战
Debian 的 Git 迁移面临几个重要的大规模协作挑战：
1. 遗留系统集成
目前，Git 存储库仅包含基于 Git 的软件包更新（tag2upload 和 dgit push）的 Git 数据。传统的基于 dput 的上传目前不存在于该存储库中。这意味着基于 Git 和遗留的上传必须在客户端通过dgit clone解决。项目计划开发一个完整的存档 dsc 导入器，开始将遗留上传导入 Git。
2. 文档和培训需求
Debian 的所有文档都需要更新，特别是打包说明，以推荐使用 Git 优先的工作流。项目团队指出："我们，Git 迁移团队，是技术专家，可以提供良好的建议。但我们没有足够的带宽来进行必要的大规模教育和文档更新活动 —— 特别是考虑到（与任何变革计划一样）许多人会持怀疑态度甚至敌意。"
3. 安全发布流程
安全修补是一个特别受益于更好、更正式使用 Git 的任务。基于 Git 的方法来应用和后端安全补丁比处理实际的补丁文件要方便得多。目前，虽然可以使用 Git 帮助准备安全上传，但通常需要从缺少适当 Git 历史的 dsc 导入开始，或者在 Salsa 上找出软件包维护者非标准化的 Git 使用约定。而且，无法正确地将安全发布作为 Git执行。
4. 内部消费者迁移
构建服务器、质量保证工作（如 lintian 检查）等内部 Debian 消费者如果不需要处理源包，可能会更简单。由于 Git 实际上是规范形式，项目希望它们直接使用它。
技术实现细节与参数
dgit 的关键参数配置
对于希望参与迁移的开发者，以下是一些关键的技术参数和配置：
- dgit 克隆命令：
dgit clone package-name- 从 Debian 存档克隆软件包到本地 Git 仓库 - tag2upload 标签格式：必须遵循
debian/version格式，例如debian/2.24.0+dfsg-3 - 签名要求：所有推送到
*.dgit.debian.org的标签必须使用有效的 PGP 密钥签名 - 元数据标准：标签必须包含标准化的元数据，提供可追溯性回到上传的 Debian 贡献者
迁移检查清单
对于维护者准备迁移，建议遵循以下检查清单：
- 确保软件包使用
3.0 (quilt)源格式或更新的格式 - 验证现有的 Git 分支是否与 dgit 视图兼容
- 配置本地 Git 以使用签名标签
- 测试
dgit clone和dgit push工作流 - 更新
debian/control中的 Vcs-* 字段 - 考虑迁移到
git-debrebase进行补丁管理
监控和调试要点
在迁移过程中，以下监控点至关重要：
- 转换一致性：定期验证 dsc 到 Git 的转换是否保持双向无损
- 性能指标：监控
dgit clone和tag2upload操作的延迟和成功率 - 采用率跟踪：跟踪基于 Git 的上传占总上传的比例
- 错误模式分析：收集和分析迁移过程中出现的常见错误模式
未来展望与挑战
Debian 的 Git 迁移是一个长期而复杂的过程。项目团队承认："几十年来，Debian 一直围绕源包构建。替换它们是一个漫长而复杂的过程。当然，源包在可预见的未来将继续得到支持。"
未来的技术路线图包括：完整的存档 dsc 导入器、对security.debian.org的基于 Git 上传支持、内部 Debian 消费者切换到从 Git 获取源代码，以及解决可能出现的不可预见问题。
从更广泛的视角看，Debian 的 Git 迁移代表了大型开源项目如何适应现代开发实践的重要案例。它展示了在保持向后兼容性的同时进行根本性架构变革的可行性，以及社区驱动项目在技术演进中的独特挑战和机遇。
结论
Debian 向 Git 的迁移不仅仅是一个版本控制系统的更换，它代表了开源软件开发方法的根本性转变。通过采用现代版本控制实践，Debian 不仅提高了开发效率，还增强了源代码的可访问性和可重复性。
这一迁移的成功实施将为其他大型开源项目提供宝贵的经验教训。它展示了如何在保持系统稳定性的同时进行渐进式变革，如何平衡技术理想主义与实际约束，以及如何通过精心设计的工具和流程促进社区采用。
正如项目文档所强调的："Git 是修改的首选形式。"Debian 的 Git 迁移确保了这一原则在整个项目中的贯彻实施，为未来几十年的开源协作奠定了坚实的基础。
资料来源：
- diziet | Debian's git transition - https://diziet.dreamwidth.org/20436.html
- gitcvs-migration(7) - Debian manpages - https://manpages.debian.org/testing/git-man/gitcvs-migration.7.en.html