XanoThis page focuses on CLI-driven workflows with Git. If your team works primarily in the Xano dashboard, see Branching & Merging for Xano’s built-in branch management and Real-time Collaboration for live co-editing.
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 Core Workflow
Create a Xano branch for your feature
Each feature gets its own Xano branch — a full runtime environment where you can develop and test.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.
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.
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.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.
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:The CLI shows a push preview of exactly what will be created, updated, or deleted before prompting for confirmation.
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: Alice opens a PR. She can include--dry-run output to show what the push to staging would look like:
Bob — reviews and deploys:
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.
| 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 |
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: 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.
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.Strategies for reducing conflicts
- Divide work by resource. If one developer owns the
ordersAPI group and another ownspayments, 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: The wizard lets you paste an access token directly. Store the token as a CI secret. See Profiles 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:Running tests in CI
Use workflow tests to validate changes after pushing: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:- Developer builds and tests on a Xano feature branch
- Developer pulls to Git and opens a PR
- CI runs
--dry-runto validate the push - Team reviews the PR diff and dry-run output
- On merge to
main, CI pushes to the Xano staging branch - After verification, a team lead promotes
stagingto live
Tips for Larger Teams
Profile management
Each developer should use their own CLI profile 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 to create named snapshots of your workspace at deployment time: 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 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.What’s Next
Push & Pull
Full reference for syncing XanoScript between your filesystem and Xano
Workspaces & Branches
Create, manage, and promote Xano branches from the CLI
Workflow Tests
Run unit and workflow tests from the command line
Releases
Create versioned snapshots for rollback and deployment tracking