Share flows with Git

Flows are plain files — so Git is the collaboration layer. What to commit, what to ignore, and how a teammate goes from clone to running suite.

Bandura has no sync service, no workspace invites, no export step — because flows are plain text in your repository, Git already is the collaboration layer. This guide is the handful of conventions that make that work smoothly.

What to commit, what to ignore

my-api-tests/
├── *.aether          ✔ commit — the flows themselves
├── bandura.json      ✔ commit — environments + which secrets the project needs
├── openapi.yaml      ✔ commit — the spec, if you use self-healing
├── .env.example      ✔ commit — a template of the keys, with values blanked
└── .env              ✘ .gitignore — the actual secrets

Two rules do most of the work:

  1. .env never enters Git. Bandura’s variable system is built so it never has to: flows reference ${{ env.API_KEY }}, and the value stays local. Runtime overrides you type into the app are also stored outside the workspace, so they can’t leak into a commit either.

  2. bandura.json declares what .env must contain via requiredEnv — names only, never values:

    {
      "name": "My API Tests",
      "environments": {
        "staging": { "BASE_URL": "https://staging.api.example.com" }
      },
      "requiredEnv": [{ "name": "API_KEY", "secret": true }]
    }

    The Environments view lists these required keys (with a secret badge where marked), so what a new machine is missing is visible in the app, not tribal knowledge.

The clone → run story

What onboarding a teammate looks like:

git clone git@github.com:your-org/my-api-tests.git
  1. Open the folder in Bandura (Open Folder → browse to the clone).
  2. Check the Environments view — the required .env keys are listed; create .env and fill them (copy .env.example if you commit one).
  3. Pick an environment in the status bar and Run.

No import, no account, no “who has the latest collection” — git pull is the latest collection. And if a key is forgotten, the pre-run guard catches the unset reference before the run, naming the exact variable.

Reviewing flow changes

An .aether diff reads like a code diff — a changed assertion is one changed line:

   config:
-    check: "response.status === 200"
+    check: "response.status === 200 && response.body.items.length > 0"

Branch, PR, and review API tests exactly like the code they test. Even graph layout (ui.position) is in the file, so the arrangement you made travels to your teammate’s canvas.

What stays personal

Run history, variable overrides, your selected environment, and your AI key all live outside the workspace on each machine — never committed, never shared. Your repo carries the tests; your machine carries your state.

The same repo in CI

Because the suite is just files, CI needs one line — bandura run "flows/**/*.aether" — with secrets injected as environment variables. Details: The bandura CLI.