See exactly what a branch changed against its base.
A branch diff shows what changed between two branches — across models, specs, and attachments — on the live diagram, not just in raw YAML. It is the primary review surface: read the diff to understand a change before merging it. Architecture diffs are hard to read as text; on the diagram, reviewers see exactly how the model diverges.
What the diff shows
| Area | Changes surfaced |
|---|---|
| Models | Added, removed, and modified objects and links, highlighted on the graph |
| Specs | Page content and embedded-diagram changes |
| Attachments | Updated ERD, OpenAPI, and handbook attachments |
| Status | Uncommitted vs committed changes per branch |
Diff modes
| Mode | Use for |
|---|---|
| Side-by-side | Compare base and branch graphs next to each other |
| Overlay | See additions, removals, and changes marked on a single diagram |
Reading a diff
Pick the branches
Choose the branch under review and the branch (or commit) to compare against.
Walk the changes on the diagram
Read additions, removals, and modifications in context — objects and links are color-marked on the graph.
Preview the merged result
Confirm the combined state is what you expect before acting.
Decide
Share the visual diff with stakeholders who don’t read YAML — the branch tells its story on the diagram.
Committed and uncommitted
Each branch tracks uncommitted changes separately from its commit history. Commit before review so the diff reflects a stable, shareable state.
Tips for reviewable diffs
- Commit small, logical units so each diff has one purpose.
- Write commit messages that explain intent.
- Avoid mixing unrelated changes on one branch.
If a diff is too large to review confidently, that is a signal to split the work into smaller branches.
Last updated on