Branching
By default, every user works in the live branch. Changes made in the live branch take effect immediately — which could potentially break a production system.
Why Branching
Section titled “Why Branching”Branching lets you make changes to schemas, task templates, services, and variables in isolation. While inside a branch, all modifications are scoped to that branch and do not affect live. Once you’re done, changes can be either merged into live or discarded entirely.
Reviewing Changes
Section titled “Reviewing Changes”A branch keeps track of every schema, task template, and service you’ve changed. For each changed entity you can see a diff against live — what was created, updated, moved, or deleted — so you can review exactly what a merge would apply before committing to it.
An entity you edited and then changed back to match live again drops out of the diff automatically: only real differences are listed.
Merging
Section titled “Merging”Merging applies all of a branch’s changes to live in a single step. Because merging touches live, it is subject to a few checks:
- You need the right access. Merging an entity requires write access to it in its target location — a participant who can only view an entity won’t be able to merge changes to it.
- Task templates must be valid. A task template with graph or type errors can’t be merged until those errors are fixed.
- There must be no unresolved conflicts, and any entity that live has moved on for must be rebased first (see below).
Conflicts
Section titled “Conflicts”A conflict happens when the same thing was changed in both your branch and in live after you created the branch — for example, you and a teammate both edited the same node in a task template.
- Some conflicts are warnings and don’t block the merge (for instance, your branch modifies an entity that was deleted in live — merging simply recreates it).
- Others block the merge until you resolve them, by rebasing or reverting the affected entity.
When Live Has Moved On
Section titled “When Live Has Moved On”While you work in a branch, your version of each entity is frozen against changes made to live after you first edited that entity. This freeze is per entity — a branch still picks up live changes to entities it hasn’t touched.
If live later changes an entity you’ve also changed, the branch flags it as outdated (“the base has moved on”). Before you can merge that entity, you rebase it: Requence performs a three-way merge that pulls the live changes into your branch’s version. By default your changes win on any direct conflict; to keep live’s version of a particular change instead, revert the entity (below).
Reverting
Section titled “Reverting”Reverting discards your branch’s changes to a single entity and restores it to live’s current version — without discarding the whole branch. Use it to drop one change you no longer want, or to accept live’s version of an entity after live has moved on.
To throw away all of a branch’s changes at once, discard the entire branch instead.
Access & Permissions
Section titled “Access & Permissions”Even when a user does not have write access to entities in an organization, group, or project, they are always allowed to create a branch and make changes — as long as they have permission to view the entities. This makes branching a safe way to propose changes without needing elevated permissions.
Since the branch creator may not have merge rights, branches can be shared with other users.
| Action | Who can do it |
|---|---|
| Edit the branch | Branch owner only |
| Discard the branch | Branch owner only |
| Merge into live | Anyone participating in the branch (with merge rights) |
Using Branches via API
Section titled “Using Branches via API”Once a user has access to a non-live branch — either by creating it or having it shared — they can point an access token to that branch. When a task is then triggered via the API, it will use the branched versions of schemas, task templates, and services instead of the live ones.
Combining with Dev Overlay
Section titled “Combining with Dev Overlay”When working on a branch, you can combine it with Dev Overlay to also test service implementation changes locally — without touching the published version of either the service definition or its code.