Version Control
Sedaro provides platform-native version control for the content in a Workspace. Teams can work on isolated branches, record coherent snapshots of their work, and compare, combine, or restore changes without managing version history for each resource separately.
Core Concepts
A Branch is a named line of work. Each branch points to a current Checkpoint, which represents the state of the Workspace at a point in time. Changes made on a branch remain uncheckpointed until you create a checkpoint. A closed checkpoint is immutable and can be opened as a read-only view of the Workspace.
Checkpoints select concrete versions of resources such as Folders, Files, Series Data, and Workflow Instances. These resources have a stable logical identity and an immutable version history. Editing or moving a resource creates a new version rather than overwriting the previous one. Folders are versioned as well, so the organization and contents of a Project can differ between branches and checkpoints.
Resource versions and checkpoints represent different levels of history. A resource version records one revision of one resource; a checkpoint records the versions selected across the Workspace.
Working With Branches
In Studio, you can:
- create a branch from another branch or checkpoint
- switch between branch contexts
- checkpoint the current changes with a name
- revert a branch to the state of an earlier checkpoint
- merge changes from one branch into another
Reverting does not remove history. It creates a new checkpoint whose state matches the selected earlier checkpoint. Merging is directional and creates a checkpoint on the target branch when it succeeds. If the branches contain conflicts, Studio reports them and the merge must be addressed before it can complete. Workflow Runs are not copied over when merging branches or creating new branches.
Workflow Instances and Git
Workflow Instances use two independent version references. Sedaro-native version control selects the instance state, while gitReference selects the workflow source code in an external Git repository. When a Workflow Run starts, it captures the exact Git commit and the native instance state used for that run. This keeps the run tied to a reproducible version even if the branch or instance changes later.