commitWorkingTree()

function commitWorkingTree(
   executor, 
   context, 
   message, 
   options
): Promise<CommitResult>;

Defined in: packages/rxdb-plugin-working-tree/src/working-tree/commit-command.ts:225

提交当前分支工作树里的全部未提交单元（FR-041）。

Parameters

Parameter	Type	Description
executor	TransactionExecutor	调用方那个写事务的执行器；本函数不自己开事务
context	CommitWriteContext	见 CommitWriteContext：造 commit 行的实体管理器与 at-rest 判定上下文
message	string	用户消息；落库前 trim，空消息由 writeCommit() 拒绝
options	CommitOptions	见 CommitOptions；三个捕获位全部必填

Returns

Promise<CommitResult>

见 CommitResult

Throws

CommitGraphCorruptedError 当前分支的提交图已损坏时（FR-051）

Throws

CommitValidationError 消息为空、或工作树是干净的（empty_commit）

Throws

NoActiveBranchError 零 active 分支时

Remarks

步骤顺序全是有理由的：

1. 先读 active 分支令牌，此后一切都打在它身上。在事务中途再查一次 active 分支 并把这笔提交归过去，是明令禁止的形态：那样永远不会失败，代价是用户在 A 分支上 看到的变更被写进 B 分支的历史。
2. 损坏守卫先于 CAS。反过来的话，一条已损坏的链上、凭据又恰好对得上的提交会直接 落库，把新节点挂到一段自己都校验不过的历史后面（FR-051）。
3. 三次比较全部先于任何写入，任一不匹配即返回 CommitConflict，此时没有 任何东西需要回滚——这正是它做成返回值而非异常的原因。
4. 写 commit → 清条目 → 单条状态 UPDATE，全在调用方那一个事务里。

干净分支上抛 empty_commit 而不是返回一个 ok: true 的空提交：空 commit 会在 历史里留下一个内容为零的节点，此后每次「没什么可提交」都长出一个，而 log() 没有 任何依据把它们藏起来。