Commits
Commits are Specor’s version control layer. Every change you make is tracked — a commit lets you package those changes into a named, immutable snapshot that you can reference, diff, and roll back to later.
The working state
When you create or edit nodes, those changes exist in the working state — live, uncommitted work that only you (and editors on the same branch) can see building up.
The working state is:
- Visible immediately — changes appear in the graph right away
- Not permanent — until committed, changes are considered in progress
- Triggering AI agents — the AI analysis runs as you work, not only after committing
You can see whether you have uncommitted changes from the commit badge in the Graph view header. It shows a count of pending changes.
Creating a commit
When you’re ready to save a named checkpoint:
- Click the Commit button (the git-commit icon) in the Graph view header
- Give the commit a clear, descriptive name — e.g.
"Add Checkout domain with Payment Processing capability" - Optionally add a longer description
- Click Create commit
The commit seals all pending events into an immutable snapshot. The working state resets to empty.
Browsing history
Click History (clock icon) in the left sidebar to see the full commit log for the active branch.
Each entry in the history shows:
- Commit name and optional description
- Timestamp and author
- A count of events in the commit
Click any commit to open the diff view — a side-by-side comparison of what was added, removed, or changed relative to the previous commit.
The diff view
The diff view shows human-readable changes:
- Added nodes — green, with their title and type
- Removed nodes — red, with their title and type
- Updated fields — amber, showing the before/after values
- Added/removed edges — showing which relationships changed
You can navigate diffs between any two commits, or between a commit and the current working state.
Comparing branches
From the Diff view you can also compare two different branches — for example, to preview what a feature branch adds before creating a merge request.
What commits enable
| Capability | How commits make it possible |
|---|---|
| Rollback | Revert to any commit’s state non-destructively |
| Merge requests | Diff a feature branch’s commits against main |
| History queries | Ask “what did the product look like at commit X?” |
| Audit trail | See who changed what and when |
Tips
- Commit often. Small, focused commits are easier to read and roll back than large batches.
- Name before committing. You can’t rename a commit after it’s sealed.
- Working state across sessions. Your uncommitted changes persist — you don’t need to commit at the end of every session.