Version history and going back

Four things you edit in CodeHerder keep a saved history of every change: a workflow, a stage in your shared stage library, a wiki page, and a task’s own fields. Each answers “can I undo this?” a little differently. This page compares the four side by side; the guide for each one covers its own history in full.

What carries a history

• A workflow — the pipeline a task’s type follows. See Customising workflows.
• A stage in your workspace’s shared stage library. See The stage library.
• A wiki page. See Workspace wiki.
• A task’s own fields — acceptance criteria, a plan, and the like. See Editing and cancelling tasks.

What a history row shows, and how to page it

Every history list reads newest first, and every one pages the same way: a batch of rows plus a cursor for the next batch, capped by --limit and continued with --cursor. A row names a version number, when it was saved, and usually who saved it. Where the item supports one, it also carries a change note.

Only the owning workspace has history

History answers at the workspace that actually owns the record. A stage or workflow your workspace inherited from a parent group, or a built-in one you’ve never customised, has no local history here — ch stage list or ch workspace workflow show name the workspace that owns it, and that’s where you’d look instead.

Going back, one item at a time

Workflow. Open the type’s page and use its version-history panel, or run ch workspace workflow versions <type>. Restore is an app-only action: click Restore on the version you want. If restoring would drop a stage that still has live tasks sitting in it, CodeHerder asks you to pick a surviving stage for them first.

Stage. Run ch stage versions <key> to read the history, with --limit and --cursor to page it. There’s no revert. To go back, open the old version, then save its content again as a fresh edit.

Wiki page. ch wiki versions <ref> lists the history; ch wiki revert <ref> <n> writes an old revision back as a new one, and the app’s page view offers the same Restore button. See Workspace wiki for the full detail, including why a revert can refuse a version whose own body was saved cut short.

Task field. The task page’s prior versions disclosure, or ch task fields versions <task> <key> from the CLI, is read-only — there’s no way to restore an old value. See below for what actually lands there.

A task field’s history isn’t an edit log

A field’s prior versions don’t come from ordinary edits — writing to a field just changes its current value, no history kept. They come from a backward move: sending a task back to an earlier stage, the way a rejected review sends it back to build. Only then does CodeHerder archive the field’s current value before resetting it, so whoever picks the work back up can still see what was there before. An empty history means this field has never been reset by a backward move. Not every field resets on one, though. A field the earlier stage can still write keeps its value. So does the merge request link, until the change actually lands.

Related guides

• Customising workflows — a workflow’s own version history and Restore flow
• The stage library — a stage’s version history in full
• Workspace wiki — a wiki page’s revision history, Compare, and Restore
• Editing and cancelling tasks — per-task fields, and when each one can be written