> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gorules.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Review & save
> Review your changes, run pre-flight checks, and save them to a branch.
Your project workspace is a draft. Edits you make stay on your device until you save them, so you can experiment freely without affecting anyone else. When you're ready to make your work permanent, the Review page shows you exactly what changed, checks that everything is in good shape, and saves your changes to a branch.
To open it, click the black **Review** button in the sidebar.
## What you'll see
The heading at the top tells you where you stand:
| Heading | Meaning |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| Ready to publish | You have unsaved changes, listed below with a summary such as "3 changes ready · 1 added · 2 modified". |
| Nothing to publish | You haven't changed anything since the last save. |
| All caught up | Everything is saved and your branch is in sync. |
Below the heading, each changed file appears with its type of change: added, modified, deleted, or renamed. Review the list before saving - if something shouldn't be there, you can revert it from the Changes panel in the workspace sidebar.
## Pre-flight checks
The Pre-flight card runs a series of checks on your draft. Each check reports one of four results: passing, warning, failing, or informational. The card headline summarises the worst result - from "All checks have passed" through "Pre-flight has warnings" to "Issues need attention".
### Sync
Confirms your draft is up to date with the server. "Working tree in sync with remote" means you're good to go. If a teammate saved to the same branch first, you'll see "Remote has newer commits" with a **Pull remote** action - pull before saving to avoid losing work. If your changes overlap with theirs, the check shows "Conflicts detected with remote" and tracks how many you've resolved. Once every conflict is settled, it reads "Conflicts resolved" and offers **Apply merge**. See [Branches](/brms/review/branches) for how conflict resolution works.
### Tests
Runs the test cases on your branch and reports the result: "All 12 test cases passing", a failing count such as "3 failing cases", "2 test files not yet run" if some haven't executed, or "No tests on this branch" if none exist. Learn how to add tests in [Testing](/brms/build/testing).
### Static analysis
Scans your rules for structural problems, such as broken references or invalid expressions. It reports "Static analysis passing", or a count of errors or warnings.
### Environments and reviews
Pre-flight also tells you how many deployment environments are available (or warns "No deployment environments configured"), flags any open reviews on the branch, and shows the previous published version for context.
Failing tests or static analysis errors turn the check red, but they don't stop you from saving. This lets you save work in progress. The states that do block saving are an out-of-sync or conflicted draft, and branch protection on the target branch.
## Where to publish
On the default branch, the "Where to publish" section offers two cards:
* **Save to main** commits your changes directly to the active branch. Use this for changes that don't need review, on projects where main isn't protected.
* **New branch** branches off the current commit and saves your changes there. The BRMS suggests a branch name, which you can edit. Click **Create branch & save** to confirm.
The commit message field is pre-filled with a summary of your changes, such as "Update Pricing and 3 more". Replace it with something more descriptive if the summary doesn't capture the intent.
If main is protected, direct saves are unavailable and you'll see a notice that approvals are required. Save to a new branch and open a review instead - the [Requests](/brms/review/requests) page walks you through the approval flow.
## Saving on a branch
On any branch other than the default, saving commits your changes to that branch. Once the branch has commits ahead of main, the Review page offers two ways forward:
* **Create merge request** opens a request so teammates can review and approve the changes before they reach main. The request appears on the [Requests](/brms/review/requests) page.
* **Merge to main** merges directly. This is available when the project doesn't require approvals and the branch is up to date with main.
If main has moved ahead of your branch, you'll be asked to pull from main first - see [Branches](/brms/review/branches#keeping-a-branch-in-sync) for details.
Once your changes are on main, you can package them into a release and deploy them. See [Releases](/brms/deploy/releases).