Skip to content

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:

  1. Click the Commit button (the git-commit icon) in the Graph view header
  2. Give the commit a clear, descriptive name — e.g. "Add Checkout domain with Payment Processing capability"
  3. Optionally add a longer description
  4. 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

CapabilityHow commits make it possible
RollbackRevert to any commit’s state non-destructively
Merge requestsDiff a feature branch’s commits against main
History queriesAsk “what did the product look like at commit X?”
Audit trailSee 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.