揭秘 Beads 底层：如何用 SQL 引擎重构 Git 的分支逻辑？

作为一个整天和 Git 补丁、分支冲突打交道的开发者，你有没有想过：如果我们的任务追踪器本身就是一个“能跑 SQL 的 Git”，会发生什么？

这正是 Beads (bd) 最硬核的技术底色。它没有选择随大流地把数据存成容易损坏的 JSON 或杂乱的 YAML，而是选择了一套惊世骇俗的方案：在 Dolt（一个实现了 Git 语义的 SQL 数据库）之上构建任务逻辑。如果你对 Dolt 数据库任务追踪原理 感兴趣，这篇文章将带你拆解它是如何重构版本控制逻辑的。

💡 报错现象总结：在大规模多人协作或 Agent 并行写入时，传统的本地任务工具常因文件锁冲突导致数据损坏。Beads 通过引入数据库级的分支（Branch）与隔离事务机制，从底层解决了“状态不一致”的问题，但也要求开发者理解“任务即数据”的存储本质。

---

任务即提交：Beads 的底层存储哲学

在 Beads 的世界里，你执行的每一次 bd create 或 bd update，在底层都不是简单的文件追加，而是触发了一次带有事务保护的数据库 Commit。

技术架构降维打击：存储映射逻辑

组件层级	实现方式	技术调性	架构师深度剖析
存储引擎	Dolt (Storage Engine)	强事务 + 版本化	将 Git 的 Commit/Branch 逻辑下沉到存储层
元数据层	System Metadata Tables	结构化 Schema	前缀、角色权限被持久化在数据库系统表中
业务逻辑	Go-based CLI (Beads)	领域模型驱动	将复杂的 SQL 递归查询抽象为极简的命令
交互接口	SQL / CLI / API	极致可扩展	支持直接用标准 SQL 客户端进行任务审计

---

深入分析：为什么“能跑 SQL 的 Git”是降维打击？

当你执行 bd prime 进行状态流转时，Beads 内部运行的是严谨的 SQL 逻辑。它不仅修改一个 status 字段，还会触发针对任务拓扑图的完整性检查。

-- 模拟 Beads 内部的任务状态变更
BEGIN;
-- 确保任务不仅存在，且其前置依赖已全部完成
UPDATE beads SET status = 'in_progress', updated_at = NOW() 
WHERE id = 'bd-a1b2' AND status = 'ready';
-- 关键：Dolt 会自动为这次修改生成一个全局唯一的哈希值（Commit Hash）
COMMIT;

这种架构意味着，你可以像在 Git 里切换代码分支一样，为你的任务列表开一个 feature-refactor 分支。在那个分支里，你可以尽情尝试不同的任务拆解路径，确认无误后，再一键 merge 回主干。这种“数据库级分支”的能力，是任何基于文本的工具（如 Jira 或 Trello）都无法模拟的。

---

痛苦的临时方案：为何“手动处理冲突”是技术倒退？

在使用基于文件的任务工具时，一旦多人同时修改，你通常要面对一堆带有 <<<<<<< HEAD 标志的冲突文件。

而在 Beads 中：

1. 行级隔离：数据库天然处理并发，不同任务的修改互不干扰。
2. 逻辑合并：利用 Dolt 的 dolt_merge 逻辑，任务状态的合并可以基于业务规则（Schema）而非简单的文本行对比。
3. 可追溯性：你可以利用 SELECT * FROM dolt_log_beads 查出谁在什么时候、因为什么原因修改了任务权重。

---

降维打击：查看 Beads 底层数据结构定义表

如果你是一名追求极致性能的极客，或者想根据自己的业务流定制一套任务系统，了解它的骨架是第一步。

我已经将 Beads 底层的 Dolt 数据结构定义表（Schema） 完整导出并进行了详细标注，同步到了 GitCode 仓库。你可以清晰地看到任务、依赖、标签和元数据是如何通过 SQL 关联起来的，以及我们是如何利用数据库索引来提升千万级任务下的查询性能。

不要满足于只使用工具，去掌握它的骨架。 这种针对底层引擎的剖析，能帮你构建出更稳健的自动化系统。前往 GitCode，看看 100KB 的代码是如何撬动一整个 SQL 引擎的。

[点击前往 GitCode 查看 Beads 底层数据结构定义表]