Mega 是一个去中心化的 Monorepo 引擎项目，旨在通过重构 Git 底层协议，构建高性能、抗审查的分布式代码协作网络。它致力于解决中心化平台垄断和传统 Git 在大规模仓库下的性能瓶颈问题。项目申请 20,000 美元资助，计划分三个里程碑交付面向个人开发者的客户端、去中心化网络及推广活动。
Note: Summary is automatically generated by AI and may differ from the original text. For reference only.
Mega 是一个代码管理的 Monorepo 引擎，其灵感来源于 Google 内部的 Piper 系统。Mega 的核心目标是：
• 为管理大规模代码库提供一个兼容 Git 的高性能 Monorepo 解决方案。
• 通过重构 Git 底层协议并结合去中心化技术，构建一个去中心化、分布式的开源代码协作网络和生态。
• 将企业级 Monorepo 引擎精简为个人代码管理应用，通过去中心化协议连接这些应用，从而构建协作网络。
项目官网：https://gitmega.dev
代码仓库：https://github.com/web3infra-foundation/mega
法律实体：Web3 Infrastructure Foundation (香港)
Mega 致力于解决开源代码协作中的两大核心问题：
• 中心化垄断与地缘政治风险：当前开源代码高度集中在少数中心化托管平台（如 GitHub）。这导致开源协作受到地缘政治、服务封禁和中心化实体控制的风险影响。Mega 通过构建去中心化网络，保障开源项目抗审查的可用性。
• Monorepo 性能与扩展性：传统 Git 在处理大规模 Monorepo（单体仓库）时存在性能瓶颈。Mega 从底层重写 Git 协议和存储层，为 Monorepo 提供可扩展、高性能的基础设施。
GitHub/GitLab 是中心化托管平台。Mega 是去中心化的代码协作网络，旨在打破中心化垄断。Radicle 在 Git 之上使用过滤器插件（git-filter）实现去中心化，核心 Git 机制未改动。Mega 从底层重写 Git 的存储和协议，提供数据库存储、Delta 压缩优化、智能加速等多项增强功能，具备更高的性能和扩展性。
传统 Monorepo 工具通常面向企业级部署。Mega 致力于将 Monorepo 引擎精简为个人开发者应用，并通过 P2P 网络连接，构建面向个人的去中心化协作生态。
• 马全一 (Quanyi Ma)：负责项目开发和管理。目前就职于华为技术有限公司，任开源运营总监。
• 王永和：负责项目推广和布道。目前全职从事此工作。
1）配合 GCC 的捐赠宣发，包括但不限于接受访谈、社媒内容制作配合、社媒转发、活动参与等。
2）在 GitHub 仓库和官网将 GCC 列为支持方之一。
3）如果项目产生盈利，计划通过 GCC 或类似机制将一定比例的收益回馈给公共物品，如支持在校学生参与开源项目等。
4）为 GCC 推荐开源项目，推动 GCC 与国内开源组织的合作。
里程碑 0 - 投票通过即解锁 20% 4000U
里程碑 1 - 解锁 20% 4000U
预计解锁日期：2026-05-31
里程碑 2 - 解锁 30% 6000U
预计解锁日期：2026-09-30
里程碑 3 - 解锁 30% 6000U
预计解锁日期：2026-12-31
附：投委打分及意见
| 解决问题的公共性 | 赛道潜力 | 对华语区（潜在）贡献 | 执行能力与团队 | 可持续性 | 平均分 |
|---|---|---|---|---|---|
| 3.15 | |||||
| 3 | 4 | 3 | 3 | 4 | 3.4 |
| 4 | 3 | 3 | 4 | 3 | 3.4 |
| 3 | 3 | 3 | 4 | 3 | 3.2 |
| 4 | 2 | 2 | 2 | 3 | 2.6 |
附：Demo Day 记录
Q1：这个项目是给大公司使用的吗？小型项目或个人开发者能用得上吗？
• 回答： Mega 整体方向分为两层。面向企业的部分提供大型 Monorepo 的企业级能力，但本次申请的项目重点是给个人开发者打造一个真正去中心化、可直接运行在本地的协作系统。它更像是 Radicle 的替代方案，但底层能力更强、性能更高，专注于个人开发者的应用场景。
Q2：Mega 目前是否得到公司资源支持？是否有其他资金来源？
• 回答： Mega 所有去中心化相关的研发都挂在 Web3 Infra Foundation (香港) 下，与公司主营业务无关，也没有商业化收入支撑。目前除中科院软件所的开源实习生之外，没有其他资金来源。本次资助是推进项目必要且唯一的资源来源，主要用于雇佣前端与全职开发者。
Q3：Mega 与 Radicle 的本质区别是什么？为何需要重新做？
• 回答： Radicle 的模式是在 Git 之上加过滤器插件（git-filter），核心 Git 机制没有改动，可扩展性有限。
• Mega 从底层重写 Git：重新实现了存储协议、优化了 Delta 和 Packfile、提供数据库级别的对象存储能力、允许从多节点获取某个对象（Radicle 做不到）。
• 这意味着 Mega 不仅能完全兼容 Git，还能**“重新定义 Git 体验”，尤其在大规模仓库、弱网环境、分布式协作下有巨大性能优势。
Q4：Radicle 是点对点传输，那 Mega 的 P2P 能做到什么额外能力？
• 回答： Radicle 的点对点传输依赖双方在线。Mega 可以做到：
◦ 分片对象存在不同节点。
◦ 即便原始节点下线，也能从其他节点重组出完整仓库**（网络本身是“可恢复的”）。
◦ 智能路由 + Gossip + QUIC 多路复用。
Q5：Mega 此前两个版本为什么没有继续推进？这次方案为何更可行？
• 回答：
◦ 纯 DHT 方案在中国网络环境实际穿透效果不佳。
◦ ZTM 方案编译、跨平台、C++ 维护成本太高。
◦ 本次采用 Rust QUIC + Gossip 的方案：完全可控、底层依赖统一、与 Mega 现有的 Rust Git 内核深度整合。理论和工程成熟度都明显更高，是最稳定和可落地的版本。
Q6：Mega 最终交付的形态是什么？能实际怎么看到？
• 回答： 最终产出包括：
◦ 完整可运行的 Monorepo 引擎（面向个人开发者）。
◦ 本地 GUI 客户端（通过资助雇佣前端打造）。
◦ 基于 QUIC 的去中心化协作网络和 Relay 节点开源。
◦ CLI 工具与 Git 完全兼容，以及将仓库 mount 成本机文件系统的 FUSE 层。
◦ 最终将发布 v0.1.0，并在香港与新加坡举办 Meetup 推广。
Q7：这个方向有哪些实际应用场景？是否会有人真正使用？
• 回答： 核心使用场景来自两类用户：
◦ 深度开源开发者：不希望依赖 GitHub/GitLab。
◦ Web3 / 去中心化生态：需要真正无需中心节点的协作方式。
• Mega 的长期愿景是让“开源协作”不必依赖任何中心平台，所有人都可用自己的设备参与协作，是对开源生态至关重要的基础设施。
PPT链接：
Mega for GCC Cohort1 Demo Day - 20251113.pdf