See exactly what a branch changed against its base.
A branch diff shows what changed between two branches — across models, specs, and artifacts — 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 |
| Artifacts | Updated ERD, OpenAPI, and workflow artifacts |
| 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
Merge in Studio on approval, or request changes on the branch.
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