尧图网站建设 
Beads 合并冲突完全指南基于 Dolt 存储的检测、解决与验证实战【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads导读Beads 以 Dolt 作为存储后端把 issue 数据保存在一个类似 Git 的 SQL 数据库中因此多端同步bd dolt pull/bd dolt push、bd sync天然会面临三路合并three-way merge产生的行级冲突。本文以仓库中的 .agent/workflows/resolve-beads-conflict.md 为核心骨架结合cmd/bd下的真实实现系统讲解冲突的检测入口、SQL 级解决方案、仓库内置的bd conflicts操作面、验证与收尾流程以及遗留 JSONL 设置的迁移路径。读完你将掌握一套可复制、可自动化、有源码依据的 Beads 冲突处理工作流。Beads 使用 Dolt 作为存储后端。Dolt 像 Git 一样原生支持三路合并three-way merge它把每次写入提交成带哈希的历史pull时以本地、远端与共同祖先merge base三方比对自动合并无冲突的改动只有同一行的同一字段被双方分别修改时才会产生真正的冲突。理解这一点是后续所有排查工作的前提——绝大多数 pull 并不会冲突冲突恰恰说明两端在同步间隔内对同一批 issue 做了互相矛盾的修改。1. 冲突检测两条互补的检查入口原文档给出的第一步是两条命令bd doctor bd dolt pull1.1 bd doctor结构化健康扫描bd doctor是 Beads 的体检工具会从多个维度检查数据库健康状态其中专门包含对 Dolt 合并冲突的检查。在 cmd/bd/doctor/validation.go 中可以看到两条路径Dolt 后端checkDoltConflicts直接查询 Dolt 的系统表dolt_conflicts按表汇总冲突数量SELECT \table, num_conflicts FROM dolt_conflicts一旦发现未解决的冲突会给出修复建议Resolve conflicts with bd dolt conflicts resolve or dolt conflicts resolve --ours/--theirs见 cmd/bd/doctor/validation.go。遗留 JSONL 后端CheckGitConflicts扫描.beads/目录下的 JSONL 文件检测 Git 冲突标记、、发现后提示“Resolve merge conflicts in .beads/ files, then commit”见 cmd/bd/doctor/validation.go。建议先跑bd doctor而不是直接 pull它能把你尚未意识到的存量冲突一次性列出来避免 pull 在冲突基础上叠加更多合并动作。1.2 bd dolt pull拉取即探测bd dolt pullbd dolt pull从配置的 Dolt remote 拉取提交并执行合并实现位于 cmd/bd/dolt.go。如果远端没有新提交命令输出Pull complete.如果拉取的改动与本地改动发生碰撞Dolt 会在返回信息中列出发生冲突的表与行。需要区分两种行为模式源码注释明确说明见 cmd/bd/dolt.go嵌入式存储embedded进程内默认模式bd dolt pull可以带--strategy ours|theirs让 Dolt 的自动解析器直接按策略解决它不敢自动处理的冲突例如两端同时修改了同一个 issue而不是中止 pull 等待人工处理功能编号 #4992。服务端模式sql-server / server-mode--strategy不被支持pull 报告冲突后应使用bd conflicts resolve解决。另外pull 在尝试合并前会先检查dolt.local-only配置bd config unset dolt.local-only可重新启用远端同步并且当 rig 完全没有配置 remote 时bd dolt pull会打印提示并安全退出 0而不是报错——这是“没有 remote 是合法配置”的刻意设计见 cmd/bd/dolt.go。2. 解决冲突从 SQL 原语到 bd conflicts 操作面2.1 SQL 级解决Dolt 原生方案Dolt 为冲突提供了 SQL 化的解决接口。原文档给出的是最直接的方案# 查看冲突 bd sql SELECT * FROM dolt_conflicts # 按“保留己方”或“采用对方”解决 bd sql CALL dolt_conflicts_resolve(--ours) # 或者 bd sql CALL dolt_conflicts_resolve(--theirs)dolt_conflicts是 Dolt 的系统表pull合并后任何未解决的行冲突都会出现在其中CALL dolt_conflicts_resolve(--ours)与CALL dolt_conflicts_resolve(--theirs)则是表级table-level的批量解决过程——前者保留本地一侧的值后者采用远端一侧的值。这是 Dolt 引擎自带的能力因此无论通过bd sql还是裸doltCLI 执行都有效。注意语义差异--ours/--theirs的方向取决于合并发生的方向。pull 合并时“ours”指你本地工作区所在的分支通常是 mastertheirs 指刚拉下来的远端分支而在 push 失败后的同步里方向可能相反。批量解决前先用dolt_conflicts看清每个表冲突了哪些行再决定策略。2.2 面向 issue 的现代方案bd conflicts 子命令裸 Dolt CLI 的冲突命令dolt conflicts cat issues、dolt conflicts resolve --ours issues、dolt add -A dolt commit旗标面与 Git 略有差异容易踩坑。为此 Beads 在 CLI 中内置了面向 issue 的冲突操作面源码注释见 cmd/bd/conflicts.go它读取的是live working set并且可以把解决粒度从“整张表”细化到“单个 issue 的单个字段”# 列出哪些表、哪些 issue 处于冲突状态 bd conflicts list # 逐字段查看所有冲突行base/ours/theirs 三方对照 bd conflicts show # 只看某一个 issue bd conflicts show bd-1234 # 只看有分歧的字段默认或显示全部列 bd conflicts show --all-fields # 逐行解决保留己方 / 采用对方 bd conflicts resolve bd-1234 --ours bd conflicts resolve bd-1234 bd-5678 --theirs # 整表解决Dolt 的表级解析 bd conflicts resolve --all --ours bd conflicts resolve --all --table config --theirs # 收尾提交一个冲突已全部解决的合并 bd conflicts resolve --conclude关键行为均有 cmd/bd/conflicts.go 源码背书默认只显示分歧字段bd conflicts show只展示 base/ours/theirs 三方不一致的字段--all-fields才展开全部列便于聚焦真正的分叉点。冲突类别提示conflictKind会区分“both sides deleted双方删除”“we deleted / they modified我方删除、对方修改”“we modified / they deleted我方修改、对方删除”“both sides added双方新增”“both sides modified双方修改”五类帮助判断该选--ours还是--theirs见 cmd/bd/conflicts.go。策略互斥校验--ours与--theirs不能同时传--strategy ours|theirs与旗标冲突会直接报错见 cmd/bd/conflicts.go。部分解决不提交resolve 后只有当dolt_conflicts中不再有任何冲突行、且本次确实解决了内容时才会自动提交合并shouldCommitResolution的判定逻辑见 cmd/bd/conflicts.go。残留冲突时输出N conflict(s) remain; the merge is not committed yet.下一次bd conflicts list继续排查。schema 冲突与约束违反不会被 dolt_conflicts 列出bd conflicts list/resolve会额外检查 schema 冲突和约束违反mergeBlockers并给出人工处理指引——schema 冲突需要中止合并dolt merge --abort后在本地应用对方ALTER TABLE再重新合并约束违反需要清理dolt_constraint_violations_table中的违规行见 cmd/bd/conflicts.go。并发保护bd conflicts在 proxied-server 模式下不被支持requireConflictSupport因为它由代理服务器独立持有 working set。2.3 自动化场景bd sync 的冲突语义如果你的工作流使用bd sync定时同步循环需要注意它定义的三类退出语义见 cmd/bd/sync.go正常同步、合并冲突导致同步中止且未推送syncStatusConflict不会被自动解决、以及推送竞争push race类瞬时问题下一轮会自动重试。bd sync采用正向冲突检测——从结构化冲突数据合并捕获的冲突 dolt_conflicts存活行判断而不是从 pull 的退出码猜测避免把网络错误误报成冲突、或漏掉“pull 成功但留下冲突行”的情况。对 CI 而言收到冲突语义的退出码后应当路由到人工或bd conflicts resolve流程而不是盲目重试。3. 验证与收尾确认解决结果并推送冲突解决后必须验证结果并推送才算完成一轮同步# 验证解决结果列出所有 issue确认数据符合预期 bd list --json | head # 推送解决后的状态到远端 bd dolt pushbd list --json输出结构化 JSON便于 grep 或管道到jq校验关键 issue 的字段值。bd dolt push的实现细节见 cmd/bd/dolt.go支持--force覆盖远端工作集当远端存在未提交改动时使用以及--remote name指定推送到某个命名 remote。若 rig 配置了no-push: true或dolt.local-onlytruepush 会明确提示“skipping push / Remote sync is disabled”并跳过而不是报错。没有配置任何 remote 时Beads 会在征得同意交互确认或--yes后尝试从 git origin 派生并采用一个 Dolt remoteadoptGitOriginRemoteForPush用--no-adopt或环境变量BD_NO_REMOTE_ADOPT1可完全禁用自动采用。若本地与远端历史分叉无共同祖先常见于多个 agent 各自bd init后推同一 remote会打印三种恢复选项bd bootstrap重克隆保留远端、bd dolt push --force以本地为准、或删除.beads/dolt后bd bootstrap手动重建见 cmd/bd/dolt.go。Hosted Dolt 场景需要为 push/pull 设置认证环境变量DOLT_REMOTE_USER与DOLT_REMOTE_PASSWORD见 cmd/bd/dolt.go。4. 冲突后的状态一致性is_blocked 重算与合并收尾一个容易被忽略的细节合并进来的写入会绕过常规的 is_blocked 计算。因此在bd conflicts resolve提交合并后Beads 会调用RecomputeBlockedAfterMerge按解决前的 HEAD 重新计算is_blocked状态见 cmd/bd/conflicts.go保证bd ready等依赖该字段的查询不会在合并后返回过期结果。若存储后端不支持重算会打印警告提示稍后运行bd recompute-blocked。这意味着解决冲突 ≠ 任务完成还需要确认bd ready队列恢复正常才不会把已解决的 issue 误判为仍被阻塞。5. 遗留设置JSONL 合并冲突的处理如果项目还停留在旧版基于 Git 的 JSONL 设置.beads/issues.jsonl冲突形态完全不同——它不是 Dolt 行级冲突而是 Git 文本冲突标记。原文档给出的流程是# 先在编辑器中手动解决 .beads/issues.jsonl 里的 Git 冲突标记然后 bd import -i .beads/issues.jsonl git add .beads/issues.jsonl git merge --continue要点手动解决Git 会把两端修改以 HEAD//标记包裹在同一文件里需要人工决定保留哪一端的 issue 行必要时合并字段。重新导入bd import -i .beads/issues.jsonl将解决后的文件重新导入 Beads 数据库确保内存中的存储与文件一致。收尾 Git 合并git add标记已解决git merge --continue完成合并提交。这也正是bd doctor中CheckGitConflicts扫描 JSONL 冲突标记的原因——旧项目升级后doctor 会同时覆盖 Dolt 与 JSONL 两种冲突形态避免“Dolt 没冲突但 Git 合并卡住”的夹生状态。6. 完整实战流程图bd doctor / bd dolt pull │ ▼ 有冲突 ──否──► 直接同步bd dolt push / bd sync │是 ▼ bd conflicts list # 哪些表、哪些 issue 冲突 bd conflicts show [issue-id] # 逐字段看 base/ours/theirs │ ├─ 行冲突 ──► bd conflicts resolve id --ours|--theirs │ 或 --all 整表解决schema 冲突需 │ dolt merge --abort 后手动 ALTER TABLE ▼ bd conflicts list # 确认 remaining 0 │ ▼ bd list --json | head # 验证解决结果 bd dolt push # 推送必要时 --force7. 预防冲突的工程建议从源码可以提炼出几条预防性结论均出自 cmd/bd/dolt.go 与 cmd/bd/sync.go 的注释与行为多 agent 场景用bd bootstrap而非各自bd init历史分叉“no common ancestor”正是多个 agent 独立初始化后推同一 remote 造成的bd bootstrap从既有 remote 克隆可根治见 cmd/bd/dolt.go。避免两端在同步间隔内同时编辑同一 issue冲突本质是“同一行同一字段双写”。agent 职责分区、编辑后尽快bd sync能显著降低冲突概率。schema 变更升级 bd 触发迁移时先收敛再升级两端分别升级 bd 并各自跑迁移可能造成主键集不同的 schema 分叉isAncestorPKMismatchErr见 cmd/bd/dolt.go这类冲突无法自动解决、重试无效只能选一个权威 clone 用bd dolt push --force确立远端其余 clone 导出本地改动后重新bd bootstrap完整恢复指引见 cmd/bd/dolt.go。相关资源索引工作流文档.agent/workflows/resolve-beads-conflict.md冲突命令实现cmd/bd/conflicts.goDolt 同步命令pull/push/commit/remotecmd/bd/dolt.go同步循环与冲突语义cmd/bd/sync.godoctor 冲突检查cmd/bd/doctor/validation.go历史分叉 / 主键分叉恢复指引cmd/bd/dolt.go、cmd/bd/dolt.go【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Beads 合并冲突完全指南：基于 Dolt 存储的检测、解决与验证实战
Beads 合并冲突完全指南基于 Dolt 存储的检测、解决与验证实战【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads导读Beads 以 Dolt 作为存储后端把 issue 数据保存在一个类似 Git 的 SQL 数据库中因此多端同步bd dolt pull/bd dolt push、bd sync天然会面临三路合并three-way merge产生的行级冲突。本文以仓库中的 .agent/workflows/resolve-beads-conflict.md 为核心骨架结合cmd/bd下的真实实现系统讲解冲突的检测入口、SQL 级解决方案、仓库内置的bd conflicts操作面、验证与收尾流程以及遗留 JSONL 设置的迁移路径。读完你将掌握一套可复制、可自动化、有源码依据的 Beads 冲突处理工作流。Beads 使用 Dolt 作为存储后端。Dolt 像 Git 一样原生支持三路合并three-way merge它把每次写入提交成带哈希的历史pull时以本地、远端与共同祖先merge base三方比对自动合并无冲突的改动只有同一行的同一字段被双方分别修改时才会产生真正的冲突。理解这一点是后续所有排查工作的前提——绝大多数 pull 并不会冲突冲突恰恰说明两端在同步间隔内对同一批 issue 做了互相矛盾的修改。1. 冲突检测两条互补的检查入口原文档给出的第一步是两条命令bd doctor bd dolt pull1.1 bd doctor结构化健康扫描bd doctor是 Beads 的体检工具会从多个维度检查数据库健康状态其中专门包含对 Dolt 合并冲突的检查。在 cmd/bd/doctor/validation.go 中可以看到两条路径Dolt 后端checkDoltConflicts直接查询 Dolt 的系统表dolt_conflicts按表汇总冲突数量SELECT \table, num_conflicts FROM dolt_conflicts一旦发现未解决的冲突会给出修复建议Resolve conflicts with bd dolt conflicts resolve or dolt conflicts resolve --ours/--theirs见 cmd/bd/doctor/validation.go。遗留 JSONL 后端CheckGitConflicts扫描.beads/目录下的 JSONL 文件检测 Git 冲突标记、、发现后提示“Resolve merge conflicts in .beads/ files, then commit”见 cmd/bd/doctor/validation.go。建议先跑bd doctor而不是直接 pull它能把你尚未意识到的存量冲突一次性列出来避免 pull 在冲突基础上叠加更多合并动作。1.2 bd dolt pull拉取即探测bd dolt pullbd dolt pull从配置的 Dolt remote 拉取提交并执行合并实现位于 cmd/bd/dolt.go。如果远端没有新提交命令输出Pull complete.如果拉取的改动与本地改动发生碰撞Dolt 会在返回信息中列出发生冲突的表与行。需要区分两种行为模式源码注释明确说明见 cmd/bd/dolt.go嵌入式存储embedded进程内默认模式bd dolt pull可以带--strategy ours|theirs让 Dolt 的自动解析器直接按策略解决它不敢自动处理的冲突例如两端同时修改了同一个 issue而不是中止 pull 等待人工处理功能编号 #4992。服务端模式sql-server / server-mode--strategy不被支持pull 报告冲突后应使用bd conflicts resolve解决。另外pull 在尝试合并前会先检查dolt.local-only配置bd config unset dolt.local-only可重新启用远端同步并且当 rig 完全没有配置 remote 时bd dolt pull会打印提示并安全退出 0而不是报错——这是“没有 remote 是合法配置”的刻意设计见 cmd/bd/dolt.go。2. 解决冲突从 SQL 原语到 bd conflicts 操作面2.1 SQL 级解决Dolt 原生方案Dolt 为冲突提供了 SQL 化的解决接口。原文档给出的是最直接的方案# 查看冲突 bd sql SELECT * FROM dolt_conflicts # 按“保留己方”或“采用对方”解决 bd sql CALL dolt_conflicts_resolve(--ours) # 或者 bd sql CALL dolt_conflicts_resolve(--theirs)dolt_conflicts是 Dolt 的系统表pull合并后任何未解决的行冲突都会出现在其中CALL dolt_conflicts_resolve(--ours)与CALL dolt_conflicts_resolve(--theirs)则是表级table-level的批量解决过程——前者保留本地一侧的值后者采用远端一侧的值。这是 Dolt 引擎自带的能力因此无论通过bd sql还是裸doltCLI 执行都有效。注意语义差异--ours/--theirs的方向取决于合并发生的方向。pull 合并时“ours”指你本地工作区所在的分支通常是 mastertheirs 指刚拉下来的远端分支而在 push 失败后的同步里方向可能相反。批量解决前先用dolt_conflicts看清每个表冲突了哪些行再决定策略。2.2 面向 issue 的现代方案bd conflicts 子命令裸 Dolt CLI 的冲突命令dolt conflicts cat issues、dolt conflicts resolve --ours issues、dolt add -A dolt commit旗标面与 Git 略有差异容易踩坑。为此 Beads 在 CLI 中内置了面向 issue 的冲突操作面源码注释见 cmd/bd/conflicts.go它读取的是live working set并且可以把解决粒度从“整张表”细化到“单个 issue 的单个字段”# 列出哪些表、哪些 issue 处于冲突状态 bd conflicts list # 逐字段查看所有冲突行base/ours/theirs 三方对照 bd conflicts show # 只看某一个 issue bd conflicts show bd-1234 # 只看有分歧的字段默认或显示全部列 bd conflicts show --all-fields # 逐行解决保留己方 / 采用对方 bd conflicts resolve bd-1234 --ours bd conflicts resolve bd-1234 bd-5678 --theirs # 整表解决Dolt 的表级解析 bd conflicts resolve --all --ours bd conflicts resolve --all --table config --theirs # 收尾提交一个冲突已全部解决的合并 bd conflicts resolve --conclude关键行为均有 cmd/bd/conflicts.go 源码背书默认只显示分歧字段bd conflicts show只展示 base/ours/theirs 三方不一致的字段--all-fields才展开全部列便于聚焦真正的分叉点。冲突类别提示conflictKind会区分“both sides deleted双方删除”“we deleted / they modified我方删除、对方修改”“we modified / they deleted我方修改、对方删除”“both sides added双方新增”“both sides modified双方修改”五类帮助判断该选--ours还是--theirs见 cmd/bd/conflicts.go。策略互斥校验--ours与--theirs不能同时传--strategy ours|theirs与旗标冲突会直接报错见 cmd/bd/conflicts.go。部分解决不提交resolve 后只有当dolt_conflicts中不再有任何冲突行、且本次确实解决了内容时才会自动提交合并shouldCommitResolution的判定逻辑见 cmd/bd/conflicts.go。残留冲突时输出N conflict(s) remain; the merge is not committed yet.下一次bd conflicts list继续排查。schema 冲突与约束违反不会被 dolt_conflicts 列出bd conflicts list/resolve会额外检查 schema 冲突和约束违反mergeBlockers并给出人工处理指引——schema 冲突需要中止合并dolt merge --abort后在本地应用对方ALTER TABLE再重新合并约束违反需要清理dolt_constraint_violations_table中的违规行见 cmd/bd/conflicts.go。并发保护bd conflicts在 proxied-server 模式下不被支持requireConflictSupport因为它由代理服务器独立持有 working set。2.3 自动化场景bd sync 的冲突语义如果你的工作流使用bd sync定时同步循环需要注意它定义的三类退出语义见 cmd/bd/sync.go正常同步、合并冲突导致同步中止且未推送syncStatusConflict不会被自动解决、以及推送竞争push race类瞬时问题下一轮会自动重试。bd sync采用正向冲突检测——从结构化冲突数据合并捕获的冲突 dolt_conflicts存活行判断而不是从 pull 的退出码猜测避免把网络错误误报成冲突、或漏掉“pull 成功但留下冲突行”的情况。对 CI 而言收到冲突语义的退出码后应当路由到人工或bd conflicts resolve流程而不是盲目重试。3. 验证与收尾确认解决结果并推送冲突解决后必须验证结果并推送才算完成一轮同步# 验证解决结果列出所有 issue确认数据符合预期 bd list --json | head # 推送解决后的状态到远端 bd dolt pushbd list --json输出结构化 JSON便于 grep 或管道到jq校验关键 issue 的字段值。bd dolt push的实现细节见 cmd/bd/dolt.go支持--force覆盖远端工作集当远端存在未提交改动时使用以及--remote name指定推送到某个命名 remote。若 rig 配置了no-push: true或dolt.local-onlytruepush 会明确提示“skipping push / Remote sync is disabled”并跳过而不是报错。没有配置任何 remote 时Beads 会在征得同意交互确认或--yes后尝试从 git origin 派生并采用一个 Dolt remoteadoptGitOriginRemoteForPush用--no-adopt或环境变量BD_NO_REMOTE_ADOPT1可完全禁用自动采用。若本地与远端历史分叉无共同祖先常见于多个 agent 各自bd init后推同一 remote会打印三种恢复选项bd bootstrap重克隆保留远端、bd dolt push --force以本地为准、或删除.beads/dolt后bd bootstrap手动重建见 cmd/bd/dolt.go。Hosted Dolt 场景需要为 push/pull 设置认证环境变量DOLT_REMOTE_USER与DOLT_REMOTE_PASSWORD见 cmd/bd/dolt.go。4. 冲突后的状态一致性is_blocked 重算与合并收尾一个容易被忽略的细节合并进来的写入会绕过常规的 is_blocked 计算。因此在bd conflicts resolve提交合并后Beads 会调用RecomputeBlockedAfterMerge按解决前的 HEAD 重新计算is_blocked状态见 cmd/bd/conflicts.go保证bd ready等依赖该字段的查询不会在合并后返回过期结果。若存储后端不支持重算会打印警告提示稍后运行bd recompute-blocked。这意味着解决冲突 ≠ 任务完成还需要确认bd ready队列恢复正常才不会把已解决的 issue 误判为仍被阻塞。5. 遗留设置JSONL 合并冲突的处理如果项目还停留在旧版基于 Git 的 JSONL 设置.beads/issues.jsonl冲突形态完全不同——它不是 Dolt 行级冲突而是 Git 文本冲突标记。原文档给出的流程是# 先在编辑器中手动解决 .beads/issues.jsonl 里的 Git 冲突标记然后 bd import -i .beads/issues.jsonl git add .beads/issues.jsonl git merge --continue要点手动解决Git 会把两端修改以 HEAD//标记包裹在同一文件里需要人工决定保留哪一端的 issue 行必要时合并字段。重新导入bd import -i .beads/issues.jsonl将解决后的文件重新导入 Beads 数据库确保内存中的存储与文件一致。收尾 Git 合并git add标记已解决git merge --continue完成合并提交。这也正是bd doctor中CheckGitConflicts扫描 JSONL 冲突标记的原因——旧项目升级后doctor 会同时覆盖 Dolt 与 JSONL 两种冲突形态避免“Dolt 没冲突但 Git 合并卡住”的夹生状态。6. 完整实战流程图bd doctor / bd dolt pull │ ▼ 有冲突 ──否──► 直接同步bd dolt push / bd sync │是 ▼ bd conflicts list # 哪些表、哪些 issue 冲突 bd conflicts show [issue-id] # 逐字段看 base/ours/theirs │ ├─ 行冲突 ──► bd conflicts resolve id --ours|--theirs │ 或 --all 整表解决schema 冲突需 │ dolt merge --abort 后手动 ALTER TABLE ▼ bd conflicts list # 确认 remaining 0 │ ▼ bd list --json | head # 验证解决结果 bd dolt push # 推送必要时 --force7. 预防冲突的工程建议从源码可以提炼出几条预防性结论均出自 cmd/bd/dolt.go 与 cmd/bd/sync.go 的注释与行为多 agent 场景用bd bootstrap而非各自bd init历史分叉“no common ancestor”正是多个 agent 独立初始化后推同一 remote 造成的bd bootstrap从既有 remote 克隆可根治见 cmd/bd/dolt.go。避免两端在同步间隔内同时编辑同一 issue冲突本质是“同一行同一字段双写”。agent 职责分区、编辑后尽快bd sync能显著降低冲突概率。schema 变更升级 bd 触发迁移时先收敛再升级两端分别升级 bd 并各自跑迁移可能造成主键集不同的 schema 分叉isAncestorPKMismatchErr见 cmd/bd/dolt.go这类冲突无法自动解决、重试无效只能选一个权威 clone 用bd dolt push --force确立远端其余 clone 导出本地改动后重新bd bootstrap完整恢复指引见 cmd/bd/dolt.go。相关资源索引工作流文档.agent/workflows/resolve-beads-conflict.md冲突命令实现cmd/bd/conflicts.goDolt 同步命令pull/push/commit/remotecmd/bd/dolt.go同步循环与冲突语义cmd/bd/sync.godoctor 冲突检查cmd/bd/doctor/validation.go历史分叉 / 主键分叉恢复指引cmd/bd/dolt.go、cmd/bd/dolt.go【免费下载链接】beadsBeads - A memory upgrade for your coding agent项目地址: https://gitcode.com/GitHub_Trending/beads1/beads创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考