💻 computer science

Deforking the World of Code: A Project-Provenance Map that Recovers Cross-Forge Fork Families that Platform Graphs Cannot See

本文介绍了一种为代码世界精心构建的“去分叉”（deforking）映射图，该图通过将共享的 git 历史记录折叠为统一的簇，从而重建了跨分叉平台的项目家族，进而纠正了流行度通胀，并揭示了数以千计的在特定平台图谱中不可见的派生关系——包括多平台分叉家族及非 GitHub 根源的项目。

原作者： Audris Mockus

发布于 2026-06-30

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Audris Mockus

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，整个软件开发的历史就像一座巨大且混乱的图书馆。在这座图书馆里，有数百万本书（代码仓库）。但问题在于，许多书其实只是同一部原创故事的复印件。

在编程世界中，这被称为分叉（forking）。开发者获取一个现有的项目，将其复制，并开始自己的版本。他们可能会在这里或那里修改几行代码，但核心历史是完全相同的。

这篇论文所解决的问题是，如果你试图通过计算图书馆中每一本书的数量来衡量一个代码片段有多“受欢迎”，你会得到一个极度膨胀的数字。如果一个受欢迎的故事被复印了 10,000 次，看起来就像有 10,000 个不同的故事正在被阅读，但实际上它只是一个故事在 10,000 个不同的地方被阅读。

这篇论文引入了一个新的地图（工具），它清理了这座图书馆。它将所有的复印件重新组合在一起，并与它们的原始来源挂钩，这样研究人员就能看到真实的故事，而不是复印件带来的噪音。

以下是他们如何实现的，使用了简单的类比：

1. “共享页面”侦探

作者们意识到，在数字世界中，你无法轻易伪造历史。如果两本书共享完全相同的页面（一个特定的“提交/commit”或代码变更），它们必然是相关的。

旧方法： 他们曾尝试链接每一本共享页面的书。但这就像是在说：“如果两本书都有一页写着‘版权所有 2024’，那么它们就是同一个故事。”这是错误的！许多互不相关的书都有相同的版权页。这导致他们的地图将完全不同的故事粘合成了一个巨大的、混乱的泥团。
新方法： 他们构建了一个更聪明的地图。他们寻找的是许多共享页面，而不仅仅是一个。如果两本书共享一整个章节，它们肯定是有关系的。

2. “尺寸限制”过滤器（上限）

即使有了更聪明的地图，一些巨大的、乏味的页面（比如标准的许可协议或空白的入门模板）仍然充当着桥梁，将互不相关的故事连接在一起。

修复方案： 作者们为这些桥梁设置了一个尺寸限制。如果一个共享页面出现在超过 250 本书中，他们就会假设这只是一个通用的模板（比如标准的“服务条款”页面）并忽略它。
结果： 这打破了那些巨大的、混乱的泥团。突然之间，地图显示出了不同的故事家族，而不是一个巨大的、令人困惑的超级集群。它并没有拆散真正的家族；它只是移除了将无关事物粘在一起的胶水。

3. “真实历史”检查

作者们担心，通过切分这些巨大的泥团，他们可能会在无意中切断了一个真实的、复杂的历史故事（例如一个被翻译成多种语言并随后重新组合的大型项目）。

测试： 他们查看了地图上最大的剩余组。他们发现这并非错误，而是一个真实的、复杂的历史过程——其中一个大型项目确实吸收了其他著名项目的部分内容（比如一个主要的操作系统合并了来自 Web 浏览器的代码）。
决定： 因为这个“残留”组是由真实的、深层的历史构成的，而不是由廉价的胶水组成的，所以他们决定不再进一步切分它。他们保留了它，因为它代表了软件世界中一种真实的、复杂的关联关系。

4. 与“官方列表”对比检查

为了确保他们的地图是准确的，他们将其与 GitHub 的官方“分叉列表”（即用户手动点击“Fork”按钮生成的列表）进行了对比。

匹配情况： 当他们查看同时存在于其地图和 GitHub 列表中的项目时，匹配率达到了 99%。
惊喜发现： 他们的地图发现了 GitHub 列表遗漏的东西！
- 跨平台家族： 他们发现了在 GitHub 上开始，但随后被复制到 GitLab、Bitbucket 以及其他网站的项目家族。GitHub 的列表只能看到 GitHub 内部的情况；而这张地图能看到整个互联网上的完整家族树。
- 脱离关系的分叉： 他们发现了一些最初是副本、但后来完全重写了历史的项目，以至于它们不再与原件相连。地图正确地将这些识别为独立的实体，而官方列表可能仍认为它们是相互关联的。

5. 为什么这很重要

在此地图出现之前，如果你想知道一名程序员参与了多少个不同的项目，你可能会得到一个虚假的数字，比如“5,000 个项目”，仅仅是因为他参与了一个拥有 5,000 个副本的热门项目。

修正： 这张地图解决了这个问题。它告诉你，该程序员实际上参与了 5 个独立的项目，而不是 5,000 个。
成果： 它提供了一个清晰、准确的软件世界视图，将原始故事与复印件区分开来，甚至能识别出跨越不同网站的故事。

简而言之： 作者们构建了一个能够理清混乱的代码复制网的工具。他们使用“尺寸限制”来防止无关项目粘连在一起，通过官方记录验证了他们的工作，并发现软件世界的跨网站互联程度比我们之前预想的还要紧密。他们发布了这张地图供所有人使用，以确保未来的软件历史研究不会被海量的复印件所误导。

技术摘要：对代码世界的“去分叉”处理

问题陈述
在全球规模上挖掘软件仓库会受到分叉（forking）现象的根本性干扰。当一个上游历史被复制到数以千计的衍生仓库中时，基于原始仓库数量的标准指标（如作者分布、项目规模和依赖扇出）会被放大数个数量级。一种幼稚的“去分叉”（deforking）方法——即合并共享 Git 历史的仓库——会遭遇灾难性的失败，因为它会过度合并不相关的软件。这是因为平凡共享的提交组（例如空提交、相同的初始脚手架或模板化的 LICENSE/CI 文件）充当了“枢纽”（hubs），将原本不相干的分叉家族桥接成了巨大的、毫无意义的集群。这一现象反映了在作者身份消歧中发现的过度合并问题。

方法论
本文为 World of Code (WoC) V2604 集合提供了一份精选的去分叉映射图，该方法扩展了之前基于共享提交的方法，处理的数据集包含 58.7 亿次提交和 1.16 亿个仓库。该方法包含三个主要阶段：

枢纽-节点星型编码（Hub-Node Star Encoding）： 为了避免将共享提交的仓库连接成二次方团（ $O(N^2)$ ），作者将共享提交关系构建为一个二部图。对于每一组共享相同提交的独特仓库集合，创建一个单一的“枢纽”节点，并通过边连接到所有参与的仓库。这使编码过程线性化为 $O(N)$ 。
并行 Louvain 聚类： 使用并行 Louvain (PLM) 对生成的二部图进行聚类，以识别社区。每个社区的规范代表（排除枢纽节点）成为去分叉后的项目 $P$ 。
结构性截断（Structural Capping）： 为了防止由模板化枢纽引起的过度合并，作者引入了一个确定性的规模上限 ( $C$ )。在图构建过程中，任何规模超过 $C$ 的共享提交组都会在分配节点前被丢弃。这移除了桥接了不相关家族的“巨型枢纽”，同时保留了通过许多较小共享提交组连接的真实分叉家族。作者通过遍历 $C$ 值（具体为 $C=250$ 和 $C=500$ ）来确定最佳阈值。

关键发现与贡献

巨型集群问题与截断（实验 D1）： 若不进行截断，最大的社区将吸收 861,948 个仓库。应用 $C=250$ 的截断后，最大的集群减少到 183,654 个仓库（减少了 78.7%），并使大规模集群的尾部发生坍缩（从 13 个成员 $\ge 10^5$ 的集群减少到 1 个）。至关重要的是，该截断并未破坏真实的分叉家族；多仓库家族的数量保持稳定（从 14.34M 略微增加到 14.35M），这表明截断切断的是家族之间的桥梁，而非粉碎家族本身。
残差分析（实验 D2）： 一项使用最大截断集群的介数中心性（betweenness centrality）进行的结构诊断显示，剩余的“残差”并非聚类伪影，而是真实的共享历史。高介数节点是聚合器仓库（例如 qtwebengine-chromium、Debian 的单体仓库）——它们真实地引入（vendored）了上游历史。在作者身份图中，结构性切割会溶解巨型集群，但在项目图中，切割顶层介数节点仅使集群缩小约 20%，这证实了残差是一个密集的真实共享历史网络，不应进行手术式移除。
对开发者信号的影响（实验 D3）： 截断显著恢复了“分布”（spread）信号（即作者触及的不同项目数量）。未截断的去分叉会将平均分布从 89.6 坍缩至 4.4，从而有效地抹杀了高产多项目作者的信号。 $C=250$ 的截断将平均分布恢复到 38.2，并将拥有 $>1,000$ 个项目的作者数量从 15 个恢复到 2,213 个，同时仍能有效压缩真实的重复分叉。
外部验证（实验 D4）： 该映射通过 GitHub 声明的分叉图（根据 GHArchive ForkEvents 重构）进行验证。在两个端点均存在于 WoC 的条件下，基于提交的去分叉方法与 GitHub 声明的分叉之间存在 99.01% 的边一致性。剩余的 0.99% 差异由已完全分化或从未共享过提交的分叉组成，这符合基于提交方法的预期行为。分析还识别出 11.04% 的声明分叉父节点尚未被 WoC 摄取，这可作为完整性指标。
跨平台与脱离式分叉（实验 D5）： 由于该映射依赖于共享提交而非平台元数据，因此它能识别单平台图中不可见的分叉家族。
- 跨平台家族： 5.41% 的分叉家族跨越多个平台（例如 GitHub、GitLab、Bitbucket）。
- 非 GitHub 根源： 1.51% 的分叉家族其规范根源并不托管在 GitHub 上。
- 脱离式分叉： 分析识别出 455,550 个“硬脱离”（hard-detached）边，即声明的分叉在 WoC 中与其父节点没有共享的提交历史。其中，240,441 个代表了已经生长出独立下游树的真实独立起源。
更新的排除列表： 作者发布了一个更新的排除列表，包含 1.34 亿个子仓库（比之前的 GHTorrent 时期列表大 3.4 倍），经过精炼后仅排除那些非脱离式的分叉。

意义与主张

本文声称，该去分叉映射是进行任何全球规模软件仓库分析的必要前提构建，纠正了由分叉多样性导致的流行度和分布指标的通胀。

作者强调，其方法与平台元数据是互补的。虽然平台图（如 GitHub）仅记录在特定窗口内通过 UI 操作创建的分叉，但这种基于提交的方法可以找回跨越不同平台并能在历史脱离后依然存在的分叉关系。该映射捕捉到了平台图无法表示的“仅限 WoC”的分叉家族。

作者明确指出，未截断的映射（目前由 WoC 分发）在涉及“残差”巨型集群方面应保持原样，因为结构诊断证明它代表了真实的引入历史而非伪影。然而，他们建议未来采用 $C=250$ 的截断映射，以消除模板化导致的过度合并，并指出目前流通的未截断版本在处理由平凡共享提交桥接的不相关项目时存在过度合并的问题。

所有人工制品，包括去分叉映射、截断变体、分叉排除列表和复制代码，均作为一个与 WoC V2604 集合键关联的自包含、独立托管的软件包发布。