Source Control

Synopsis

note

Staging is a separate mechanism from source control. A staging version is a second copy of the pipeline with its own commits; syncing it back overwrites the main pipeline rather than merging into it, and does not go through the review flow described here.

Saving a pipeline in the Pipeline Editor does not change what your directors are running. A save records an uncommitted change; the change becomes live only once it has been committed and the commit merged.

This gives pipeline edits a review step. Someone authors a set of changes and commits them, someone with merge rights reviews the diff and merges or rejects, and only a merge reaches the directors. Until then the last merged version keeps running unchanged.

Source Control is a section of the Pipeline Editor's rail, alongside the pipeline explorer. It is scoped to one pipeline tree — a root pipeline and its child pipelines — so each tree has its own changes and its own commit history.

The Life of a Change

Stage	What exists	What the directors run
Saved	An uncommitted change, visible to you	The last merged version
Committed	A pending commit awaiting review	The last merged version
Merged	The change applied to the pipeline	The new version
Rejected	Nothing — the change is discarded	The last merged version

A commit is the unit of review, and a change is the unit of work: one commit carries the changes to as many pipelines in the tree as you had outstanding.

Uncommitted Changes

The Source Control section lists your saved-but-uncommitted changes for the open pipeline tree. Each card names the pipeline, its author, and how long ago it changed. Selecting a card opens that change's diff as an editor tab, so a diff sits where a pipeline would and you can read it against the rest of the tree.

The list covers more than edits. Adding a child pipeline records an added change, and deleting a pipeline records a deletion — nothing is removed outright, so a deletion is reviewed like any other change and takes effect on merge.

Action	Effect
Discard change	Reverts one pipeline to its last committed version
Discard changes	Reverts the selected pipelines to their last committed versions
Commit all changes	Opens the commit dialog for every change in the list

warning

Discarding is not recoverable. An uncommitted change has never been committed, so there is no earlier version of it to restore — the edits are simply gone.

Committing

Commit all changes asks for a Commit name and an optional Description, and lists the pipelines that will be included. Both are kept in the commit history, so the name is worth writing for the reviewer rather than for yourself.

Committing consumes the changes: the list empties, and the changes now belong to a pending commit. A commit cannot be created with nothing to commit.

While a commit is pending, the pipeline list and the pipeline detail view show a N changes are not live yet notice, with Review changes leading back here.

Commits

Switching the rail to Merge Requests lists the tree's commits, newest first, with a search field and a status filter:

Status	Meaning
Pending	Committed, awaiting review
Merged	Applied to the pipelines and deployed
Rejected	Reviewed and refused; the changes were discarded

Selecting a commit opens its detail: the name and description, the author, the commit time, and the pipelines it touches, each tagged added, modified, or removed.

A pending commit offers three actions:

• Review and merge — walk the diffs one pipeline at a time, then merge
• Merge all without review — merge without opening the diffs
• Reject commit — refuse the commit, with an optional note

Reviewing

Review and merge opens each changed pipeline's diff in turn. Accepting a change marks it reviewed, and the header tracks progress as N of M changes accepted. The review must be complete before it can be merged — the server refuses a reviewed merge that still has unaccepted changes.

You can edit a pipeline's content while reviewing it. Those edits are what gets merged, so a reviewer can correct a small mistake in place rather than rejecting the whole commit over it.

Quit review abandons the review and discards any edits made during it. The commit stays pending with its original content and can be reviewed again.

Merging

Merging applies every change in the commit to its pipeline and deploys the result to your directors immediately. A merged commit cannot be undone, but its content stays in the history and any pipeline it touched can be restored to an earlier version.

Merging requires the commit to still be pending: a commit that has already been merged or rejected cannot be merged again.

Rejecting

Reject commit refuses the commit and discards its changes; nothing reaches the directors. The optional Rejection note is kept with the commit and read from See reject notes on the rejected commit, so the reason survives for audit even after the changes are gone.

Restoring an Earlier Version

Restore to this version on a merged commit rebuilds the selected pipelines as they were in that commit. It is available on merged commits only — a pending or rejected commit was never applied, so there is no version of it to go back to.

Restoring is a two-step dialog. First select the pipelines to restore; each row states its outcome:

The commit recorded	Restoring will
modified	Return the pipeline to its previous content
added	Remove the pipeline
deleted	Add the pipeline back

Then name the restore commit and add an optional description.

A restore does not take effect on its own: it creates a new pending commit, which goes through review and merge like any other. Existing commits stay in the history, so you can restore to a different version later.

warning

A restore discards uncommitted edits to the pipelines it covers. Commit or discard outstanding work before restoring.

Requiring Unit Tests Before Merge

An organization can require that every unit test in a pipeline tree passes before its commits can be merged. When the requirement is on, the merge dialogs show a Unit tests summary reporting how many tests passed out of the total, and merging is blocked while any test has failed, errored, or never run.

A test that has never been run blocks the merge exactly as a failing one does — an unrun test establishes nothing about the change.

The requirement applies to both merge paths, and the server enforces it independently of the interface: a merge that slips past the on-screen check is still refused. See Content Settings for turning it on.

Checkpoints Are Not Commits

The editor's Checkpoints tab takes manual snapshots of a tab's content that you can roll back to. Those snapshots live in your browser's local storage: they are not shared with anyone, do not follow you to another browser or machine, and are not part of source control or of any backup. Clearing site data removes them.

Use a checkpoint to park an experiment for the next few minutes. Use a commit for anything that has to survive, be reviewed, or be seen by someone else.

Permissions

Permission	Grants
PIPELINE_EDIT	Saving, discarding, and listing uncommitted changes
PIPELINE_COMMIT_CREATE	Creating commits, reading the tree's commits, and restoring a version
PIPELINE_COMMIT_MERGE	Reading every commit in the organization, and merging or rejecting

Splitting create from merge is what separates author from reviewer: a contributor can commit work and follow it, but only a holder of PIPELINE_COMMIT_MERGE can put it live. See Roles.