Skip to main content
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.
Review page showing the Ready to publish heading, the pre-flight checks card, and the Where to publish options

The Review page with pre-flight checks expanded

​
What you’ll see

The heading at the top tells you where you stand: 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 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.

​
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 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 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 for details. Once your changes are on main, you can package them into a release and deploy them. See Releases.