> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Team Workflows

> Git branching, code review, and collaboration strategies for teams using the Xano CLI

export const BrowserFrame = props => {
  const {url = "xano.run", maxWidth = 820, className = "", lightSrc, darkSrc, alt = "", children} = props || ({});
  const style = typeof maxWidth === "number" ? {
    maxWidth: `${maxWidth}px`,
    margin: "16px 0"
  } : {
    maxWidth,
    margin: "16px 0"
  };
  const hasSwapImages = Boolean(lightSrc && darkSrc);
  return <div className={`browser-frame ${className}`.trim()} style={style}>
      <div className="browser-frame__top">
        <div className="browser-frame__controls" aria-hidden="true">
          <span className="browser-frame__dot browser-frame__dot--red" />
          <span className="browser-frame__dot browser-frame__dot--yellow" />
          <span className="browser-frame__dot browser-frame__dot--green" />
        </div>
        <div className="browser-frame__address">{url}</div>
      </div>

      <div className="browser-frame__body">
        {hasSwapImages ? <>
            <img className="browser-frame__img--light" src={lightSrc} alt={alt} />
            <img className="browser-frame__img--dark" src={darkSrc} alt={alt} />
          </> : children}
      </div>
    </div>;
};

When multiple developers work on the same Xano workspace, the CLI and Git work together to keep everyone in sync. Xano branches are where you develop and test — they're live runtime environments. Git is where you track history, review changes, and coordinate who promotes what to production.

<Note>
  This page focuses on CLI-driven workflows with Git. If your team works primarily in the Xano dashboard, see [Branching & Merging](/team-collaboration/branching-and-merging) for Xano's built-in branch management and [Real-time Collaboration](/team-collaboration/realtime-collaboration) for live co-editing.
</Note>

***

## How Git and Xano Fit Together

There are two systems involved, and each handles a different part of the workflow:

|                        | Xano                                                     | Git                                                  |
| ---------------------- | -------------------------------------------------------- | ---------------------------------------------------- |
| **Role**               | Development, testing, deployment                         | History, code review, collaboration                  |
| **Where work happens** | Xano branches — dashboard, AI tools, or CLI push         | Local filesystem — commits, diffs, PRs               |
| **Branching**          | Runtime environments you can test against                | Feature branches for isolating and reviewing changes |
| **Deployment**         | CLI `push` applies changes; `set_live` promotes a branch | Does not deploy anything                             |

The key insight: **development and testing happen on Xano branches**, because that's where your code actually runs. Git captures what was built, provides a readable diff for review, and gates when changes get promoted.

```
Xano branch ──pull──▸ Local .xs files ──commit──▸ Git PR ──review + approve──▸ CLI push ──▸ Xano staging/live
```

***

## The Core Workflow

<Steps>
  <Step title="Create a Xano branch for your feature">
    Each feature gets its own Xano branch — a full runtime environment where you can develop and test.

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      xano branch create -l orders-feature
      ```
    </BrowserFrame>

    You can also create branches from the Xano dashboard. Either way, this gives you an isolated copy of your workspace to work in without affecting staging or production.
  </Step>

  <Step title="Develop and test on the Xano branch">
    Build your feature however you normally work — the dashboard, AI tools, or editing XanoScript locally and pushing with the CLI. The important thing is that your Xano branch is a live environment: you can hit the APIs, test with real data, and iterate.

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      # If developing locally, push your changes to your feature branch
      xano workspace push -d ./my-workspace -b orders-feature
      ```
    </BrowserFrame>

    <Tip>
      Use [AI-assisted development](/getting-started-ai) with tools like Claude Code and the Xano Developer MCP to generate and modify XanoScript, then push to your feature branch for testing.
    </Tip>
  </Step>

  <Step title="Pull to Git and open a PR">
    Once your feature is working on the Xano branch, pull it down, commit, and open a pull request. The PR gives your team a readable diff of everything that changed — table schemas, endpoints, functions — in one place.

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      # Pull the tested feature branch
      xano workspace pull -d ./my-workspace -b orders-feature

      # Commit and push to Git
      cd my-workspace
      git checkout -b feature/orders-api
      git add .
      git commit -m "Add orders table and CRUD API"
      git push origin feature/orders-api
      ```
    </BrowserFrame>

    Open a PR targeting your main Git branch. Your teammates review the XanoScript diff — the review is about **"should we promote this?"**, not "does this work?" — because you've already tested it on the Xano branch.
  </Step>

  <Step title="Deploy with the CLI after approval">
    After the PR is approved, use the CLI to push the reviewed changes to your shared staging or production branch:

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      # Merge the PR in Git, then push to your Xano staging branch
      git checkout main
      git pull origin main
      xano workspace push -d ./my-workspace -b staging
      ```
    </BrowserFrame>

    The CLI shows a [push preview](/xano-cli/push-pull#push-preview) of exactly what will be created, updated, or deleted before prompting for confirmation.

    <Tip>
      You can also merge your feature branch directly in Xano using the dashboard's [branch merging](/team-collaboration/branching-and-merging) tools. The CLI push approach gives you more control over exactly what gets deployed and when.
    </Tip>
  </Step>

  <Step title="Test on staging, then promote to live">
    Validate on your staging branch, then promote when ready:

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      # Run tests against staging
      xano workflow-test run ./my-workspace -b staging

      # When satisfied, promote to live
      xano branch set_live staging
      ```
    </BrowserFrame>
  </Step>

  <Step title="Clean up">
    Delete the feature branch once it's been promoted:

    <BrowserFrame url="Terminal">
      ```bash theme={null}
      xano branch delete orders-feature
      ```
    </BrowserFrame>
  </Step>
</Steps>

***

## End-to-End Example

Here's a complete example of two developers collaborating on a feature. Alice builds and tests it, Bob reviews and deploys it.

**Alice — develops and tests the feature:**

<BrowserFrame url="Terminal">
  ```bash theme={null}
  # Create a Xano branch for the feature
  xano branch create -l orders-feature

  # Alice develops in the dashboard, with AI tools, or locally — then tests on the branch.
  # When the feature is working, pull it down for Git tracking:
  xano workspace pull -d ./acme-backend -b orders-feature
  cd acme-backend

  # Commit to Git and open a PR
  git checkout -b feature/orders-api
  git add table/order.xs api/orders/
  git commit -m "Add orders table and CRUD API"
  git push origin feature/orders-api
  ```
</BrowserFrame>

Alice opens a PR. She can include `--dry-run` output to show what the push to staging would look like:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano workspace push -d ./acme-backend -b staging --dry-run
  ```
</BrowserFrame>

**Bob — reviews and deploys:**

<BrowserFrame url="Terminal">
  ```bash theme={null}
  # Review the PR diff on GitHub — schema changes, new endpoints, function logic

  # After approving and merging the PR:
  git checkout main
  git pull origin main

  # Push the reviewed changes to Xano's staging branch
  xano workspace push -d ./acme-backend -b staging

  # Run tests, then promote to live
  xano workflow-test run ./acme-backend -b staging
  xano branch set_live staging
  ```
</BrowserFrame>

***

## Xano Branches Are Runtime Environments

Git branches and Xano branches serve fundamentally different purposes:

* **Xano branches** are live environments — your code runs there, your APIs respond, your database is real. You need them to test.
* **Git branches** are for isolation and review. They hold a snapshot of XanoScript files but can't execute anything.

This means you'll typically have **more Xano branches than just "dev" and "live."** A team of three developers might each have a feature branch on Xano at the same time, plus a shared staging branch and the live branch.

| Branch           | Purpose                                        | Lifetime                        |
| ---------------- | ---------------------------------------------- | ------------------------------- |
| `live` (or `v1`) | Production — serves real API traffic           | Permanent                       |
| `staging`        | Pre-production testing, receives reviewed code | Long-lived                      |
| `orders-feature` | Alice's feature — develop and test here        | Short-lived, delete after merge |
| `payments-fix`   | Bob's hotfix — develop and test here           | Short-lived, delete after merge |

<Tip>
  Create feature branches freely — they're cheap and give each developer an isolated environment to test in. Clean them up after merging.
</Tip>

***

## Code Review with Pull Requests

Because your code is already tested on a Xano branch before review, the PR serves a different purpose than in a traditional codebase. The question isn't "does this work?" — it's **"should we promote this to staging/production?"**

XanoScript files are plain text, so standard Git diffs work well. Here's what to focus on during review:

### Schema changes (tables)

Table diffs are the most impactful — they directly affect your database structure. Watch for:

* Renamed or removed columns (potential data loss)
* Changed field types or validation rules
* New indexes or relationships

### Logic changes (functions and APIs)

Function and API diffs are lower risk but still worth reviewing for:

* Changed input/output contracts
* Modified authentication or middleware settings
* New or removed endpoints

### Using dry-run in review

Any team member can preview the server-side impact of a push without applying changes:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano workspace push -d ./my-workspace -b staging --dry-run
  ```
</BrowserFrame>

This shows exactly what the push would create, update, or delete — including destructive schema changes. Paste the output into the PR for full visibility.

***

## Handling Conflicts

When multiple developers work on the same workspace, conflicts can surface at two levels.

### Git-level conflicts

These happen when two developers modify the same `.xs` file. Git's standard merge tools handle these — resolve them like any other code conflict, then commit the result.

<Warning>
  After resolving a Git merge conflict in a `.xs` file, review the merged result carefully. XanoScript files have a specific structure, and a bad merge can produce invalid syntax. Run a [dry-run push](/xano-cli/push-pull#push-preview) after resolving to catch issues before they reach Xano.
</Warning>

### Xano push conflicts (stale local files)

These happen when the Xano branch has changed since your last pull — for example, if a teammate pushed or made changes in the dashboard. The push preview will show unexpected diffs because your local files are out of date.

The fix: **pull before you push.**

<BrowserFrame url="Terminal">
  ```bash theme={null}
  # Refresh your local files from the target branch
  xano workspace pull -d ./my-workspace -b staging

  # See what the pull changed
  git diff

  # Commit the pulled changes, then push your work
  git add .
  git commit -m "Sync from Xano staging branch"
  xano workspace push -d ./my-workspace -b staging
  ```
</BrowserFrame>

### Strategies for reducing conflicts

* **Divide work by resource.** If one developer owns the `orders` API group and another owns `payments`, conflicts are rare.
* **Pull frequently.** The longer you go without pulling, the more drift accumulates.
* **Communicate on schema changes.** Table modifications affect everyone — flag these in your team channel before pushing.
* **Use separate Xano feature branches.** When each developer works on their own Xano branch, they can't step on each other's work until it's time to merge.

***

## CI/CD Integration

The Xano CLI runs in CI environments for automated validation and deployment.

### CI authentication

Create a dedicated profile using a token:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano profile wizard
  ```
</BrowserFrame>

The wizard lets you paste an access token directly. Store the token as a CI secret. See [Profiles](/xano-cli/profiles#profile-wizard) for details on extracting tokens and configuring non-interactive authentication.

### Validating with dry-run

Add a dry-run step to your pipeline to catch push errors before they reach Xano:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano workspace push -d ./my-workspace -b staging --dry-run
  ```
</BrowserFrame>

### Running tests in CI

Use [workflow tests](/xano-cli/workflow-tests) to validate changes after pushing:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano workflow-test run ./my-workspace -b staging
  ```
</BrowserFrame>

### Example: gating promotion behind PR approval

A common pattern is to automate the push to Xano's staging branch only after a PR is merged:

1. Developer builds and tests on a Xano feature branch
2. Developer pulls to Git and opens a PR
3. CI runs `--dry-run` to validate the push
4. Team reviews the PR diff and dry-run output
5. On merge to `main`, CI pushes to the Xano staging branch
6. After verification, a team lead promotes `staging` to live

This ensures every change is reviewed before it reaches your shared staging environment, while still giving developers the freedom to test on their own branches.

***

## Tips for Larger Teams

### Profile management

Each developer should use their own [CLI profile](/xano-cli/profiles) pointing to the same workspace. Profiles can target different branches, so each developer can default to their own feature branch without passing `-b` on every command.

For CI/CD, use a dedicated service account profile rather than a personal token.

### Versioned deployments with releases

Use [releases](/xano-cli/releases) to create named snapshots of your workspace at deployment time:

<BrowserFrame url="Terminal">
  ```bash theme={null}
  xano release create "v2.1.0" --description "Orders API + payment refactoring"
  ```
</BrowserFrame>

Releases give you a rollback point that's independent of Git history — useful when you need to revert the live Xano state without reverting Git commits.

### Git Sync for non-CLI teammates

If some team members prefer the Xano dashboard, enable [Git Sync](/xano-features/workspace-settings/git-sync) to automatically push a read-only copy of your workspace to GitHub or GitLab. This gives you visibility into dashboard-made changes in your Git history.

<Warning>
  **Git Sync is one-way** (Xano to Git). It mirrors your workspace for visibility and backup — it does **not** deploy code into Xano. The CLI is the only way to push changes to Xano from outside the dashboard.
</Warning>

***

## What's Next

<CardGroup cols={2}>
  <Card title="Push & Pull" icon="arrows-rotate" href="/xano-cli/push-pull">
    Full reference for syncing XanoScript between your filesystem and Xano
  </Card>

  <Card title="Workspaces & Branches" icon="code-branch" href="/xano-cli/workspaces-and-branches">
    Create, manage, and promote Xano branches from the CLI
  </Card>

  <Card title="Workflow Tests" icon="flask-vial" href="/xano-cli/workflow-tests">
    Run unit and workflow tests from the command line
  </Card>

  <Card title="Releases" icon="box" href="/xano-cli/releases">
    Create versioned snapshots for rollback and deployment tracking
  </Card>
</CardGroup>