How Wizata uses branches

Wizata maps the pipeline lifecycle onto branches. You do not have to manage them yourself — editing, publishing and deploying create and remove them for you — but knowing the layout makes the repository readable to anyone on your team.

This page is the repository's side of it. For the same lifecycle as it appears in the AI Lab — the branch selector, drafts, and the publish action — see Drafts and publishing.

The layout

<default branch>              published pipelines — what runs unless a ref is chosen
feature/<key>/<user>-<date>   a draft, created when someone starts editing
release/<key>/<name>          a frozen label used by a deployment

Both feature/ and release/ carry the pipeline key, so you can tell what a branch
belongs to by reading its name.

Branches that do not follow these patterns are ignored by Wizata. You can use the repository for other things, and Wizata will leave them alone.

Editing a pipeline

The first time you edit a published pipeline, Wizata creates a feature branch for you and commits your changes there. The published version keeps running untouched while you work.

Each save is a commit, so the draft's history shows how it evolved. Saving without changing anything does not create an empty commit.

Publishing

Publishing merges the feature branch into the default branch and deletes it, locally and on the remote. From then on the pipeline runs from the published version.

If someone else changed the same pipeline while you were drafting, Wizata attempts a merge. When the changes conflict, publishing stops and reports it rather than picking a winner.

Releases

Deploying creates a release branch — a fixed label on a commit that is already published. No new commits are made; the branch simply marks the exact version that a deployment runs.

A release is a snapshot of the whole repository, so it contains every pipeline. The key in the branch name records which pipeline the release was cut for, which is what keeps one pipeline's releases out of another's list.

That is what makes a deployment reproducible: the release branch keeps pointing at the same commit no matter how much the default branch moves on afterwards.

A release branch cannot be deleted while a deployment still references it. Wizata will tell you which one is holding it.

Experimenting on a branch

You can run an experiment against any branch, not just the published version — useful for testing a change against real data before publishing it.

Editing the repository directly

You can commit to the repository outside Wizata. Changes on the default branch are picked up by the background sync, so a pipeline edited in your own editor and pushed will be reflected in the platform.

Two things to keep in mind:

• Pipeline files must stay valid. A malformed JSON file cannot be loaded, and the pipeline will fail to run.
• Renaming a pipeline file changes its key, which the platform treats as a different pipeline.

📘

If you plan to edit definitions by hand regularly, do it on a branch and publish through Wizata — you get the same validation as an in-app edit.