Lore：又一个要干掉 Git 的版本控制系统

今天 Hacker News 第一名，978 分。

Lore。一个开源的版本控制系统。

看到这个消息的时候我正在 git rebase，手一抖差点把三条 commit 合错了。

说实话，"要干掉 Git"的项目我见过不少。Hg（Mercurial）死掉了，Fossil 半死不活，Pijul 还在小众圈子里活着。现在又来个 Lore。

而且这次动静不小。

Lore 的官网（lore.org）上写得很直白：Git 不是为大规模协作设计的。

它列了几个 Git 的痛点： - 仓库超过 10GB 之后，clone 和 fetch 慢得离谱 - 大型 monorepo（比如 Google 那种几百万文件的）根本撑不住 - merge 冲突解决靠运气，没有真正的语义理解 - LFS 就是个补丁，而且是个很烂的补丁

这些痛点……说实话，我全踩过。

去年我们公司把三个微服务合成一个 monorepo，Git 仓库直接膨胀到了 8GB。每次新人入职 clone 一次就要等二十分钟。后来上了 sparse checkout + partial clone，体验才好了一点。

但治标不治本。

那 Lore 怎么解决这些问题？

从技术文档来看，它做了几件事：

第一，存储层重写了。 不用 Git 的对象存储（blob + tree + commit），而是用一种叫做"增量快照链"的数据结构。每次提交只存差异，但在需要还原完整历史的时候，可以 O(1) 跳转。

这个设计让我想起了 Google 内部的 Piper。Piper 也是用类似的分层存储来管理几十亿行代码的。

第二，引入了"语义合并"。 不是简单的文本三路合并，而是能理解代码结构的合并引擎。比如你在 A 分支改了一个 Java 方法的签名，在 B 分支加了调用点——Lore 能识别出这两处改动有关联，帮你自动适配调用签名。

这个听起来很美好，但我持保留态度。语义合并的概念不新，以前 IntelliJ 的合并工具也号称能做"智能合并"，实际用起来——嗯，还是经常出错。

第三，分布式但不完全分布式。 Lore 支持一个"中心服务器"模式，可以缓存和索引大型仓库，客户端按需拉取。这有点像 Git 的 shallow clone 加上一个智能代理。

我今早试着 build 了一下 Lore 的源码。

Rust 写的，编译倒是挺快。但跑起来之后，我试着往里面导入一个 2GB 的 Git 仓库——直接 OOM 了。

好吧，毕竟是刚出来的项目。

反正我的态度是：关注，但不急着用。

Git 的问题确实存在，但 Git 的生态——GitHub、GitLab、CI/CD 工具链、IDE 集成——已经深到骨子里了。一个新系统想替代它，光技术好是不够的，生态建设至少需要三五年。

先让子弹飞一会儿吧。

关于维基框架

维基框架（Wiki Framework）是一套面向复杂业务场景的轻量级开发框架，支持多语言、多协议、多部署形态。适用于企业级应用开发、微服务架构、云原生部署等场景。