一个 10GB 的代码目录，创建新工作区低于 0.1 秒。

Rift 的卖点就这么直：别再等复制，别再为每个并行任务多付一整份磁盘成本。

它在 GitHub 上把自己称为“better alternative to git worktrees”。这句话很抓眼球，也容易把人带沟里。Rift 真正挑战的不是 Git worktree 本身，而是大仓库时代那套笨重的本地工作流：切任务慢，复制慢，保留现场贵。

Rift 做了什么：把“复制目录”交给文件系统

Rift 的核心是 copy-on-write，写时复制。

新工作区看起来像一份完整代码副本，底层尽量复用原数据。只有发生修改时，才额外写入。这就是它快和省空间的原因。

关键信息压缩成一张表：

项目Rift 当前做法现实影响
创建速度README 称 10GB 文件夹低于 0.1 秒适合频繁开临时工作区
存储占用copy-on-write，共享未修改数据大仓库更省空间
Linux依赖可写 btrfs snapshots文件系统前提很硬
macOS依赖 APFS clonefile更像文件级克隆
Windows包已发布，但工作区创建未实现暂不能当完整跨平台工具
接口CLI + Bun/Node FFI可嵌入脚本和工具链

使用路径也不复杂。

rift init 注册或转换根目录。rift create 创建子工作区，可以指定名称或目标位置。rift remove 把工作区移入相邻的 .trash。rift gc 再负责删除和清理登记。

Rift 还维护一个 SQLite registry，记录路径、父子关系和回收站条目。每个托管工作区里有 .rift 标记。默认创建出的工作区会放在源目录相邻的 .rifts 目录下。

如果工作区是 Git 仓库，新工作区会保留 index 和 working tree 状态，但处于 detached HEAD。

这个细节很关键。Rift 复制的是“现场”，不是帮你管理分支。

它和 Git worktree 的边界：一个管 Git 语义，一个管目录现场

Git worktree 解决的是另一件事：同一个仓库，多条分支，多份工作目录，还在 Git 原生命令体系里。

它的长处是语义清楚。分支、提交、checkout、工作树关系，都贴着 Git 模型走。

Rift 更像文件系统级快照工作区。它把“给我一份完整目录现场”做快，把空间占用压低。后面怎么 checkout、怎么提交、怎么处理 detached HEAD，仍然是 Git 的事。

两者边界大概是这样：

场景更像 Git worktree更像 Rift
长期维护多个分支是不一定
快速保留当前脏工作区现场不擅长擅长
大仓库多任务并行试验可用，但成本更显眼更贴合
依赖 Git 原生分支语义强弱
受文件系统能力影响低高

所以，不要把 Rift 理解成“新 Git 命令”。

它更像在 Git 旁边放了一台高速复印机。只是这台复印机不靠傻复制，而是借了文件系统的力。

对大仓库、多分支并行开发的工程师，动作很明确：可以把 Rift 放到临时实验、保留脏现场、并行跑构建这类场景里试。不要一上来替换 Git worktree。

对关心本地工作流效率的团队，更现实的做法是观望加小范围验证。先看仓库体积、文件系统、IDE、包管理器、构建缓存是否合拍。Linux 不是 btrfs，就别急着写进团队规范。Windows 还没实现工作区创建，也不适合做跨平台默认方案。

我的判断：刀切得准，但刀柄在文件系统手里

我喜欢 Rift 的地方，是它没有装成万能协作平台，也没有重新发明版本控制。

它盯住一个很疼的点：大仓库里同时处理多个任务，复制慢，占空间，切来切去还容易污染现场。

这个痛点很真实。很多现代开发工作流的卡顿，不在 Git 命令本身，而在目录太重。依赖、缓存、构建产物、生成文件，全都堆在本地工作区里。工具链越现代，工作区越像超载卡车。

Rift 的聪明，是借势。

古人说“善战者，求之于势”。放到这里，“势”就是 btrfs 和 APFS 已经提供的底层能力。你不硬搬 10GB 数据，速度自然不会像传统复制那样难看。

但代价也清楚。

Linux 要 btrfs writable snapshot。macOS 要 APFS clonefile。Windows 现在还没实现工作区创建。对个人开发者，这可能只是换个目录的问题。对公司环境，就是另一回事：老机器、统一镜像、安全策略、CI 习惯、跨平台开发，都可能卡住。

我不太买账的是“替代 Git worktree”这个说法。

传播上好用，技术上容易误导。Rift 替代的不是 Git worktree 的全部价值，而是部分场景里“我要一份完整工作现场”的高成本动作。

它最适合大仓库玩家：前端 monorepo、复杂后端服务、频繁开实验分支的工程师、写开发工具链的人。小仓库、轻量项目、正常切分支就够用的开发者，收益未必明显。

接下来要看三件事。

一是异常恢复稳不稳。registry、.rift、.trash 如果乱了，工具自己就会变成新负担。

二是和现有工具能不能和平相处。IDE、包管理器、构建缓存、Git 操作，任何一个频繁误判路径或状态，都会抵消速度优势。

三是跨平台路线怎么补。没有 Windows 工作区创建能力，它就很难成为团队级默认工具。

开发者工具最怕只在演示里快。快是入场券，少出事才是通行证。

Rift 这件事有意思，不在于它喊了 Git worktree，而在于它提醒我们：很多开发效率问题，表面是 Git，底层是文件系统；表面是分支，底层是大仓库时代的重量。

刀要落在这里，才算切到筋骨。