--branch <name>.
The safe path to production
- Create a Branch for the change.
- Deploy that Branch to Preview.
- Review its code and content changes.
- Merge the Branch into
main. - Publish
mainto production.
Work with Branches
fimo checkout -b instead of git checkout -b. The Fimo command creates both the Git branch and its isolated Fimo environment.
Resolve merge conflicts
When both Branches changed the same item,fimo merge stops before applying anything. In a terminal it asks how to resolve each conflict: keep the current Branch’s value, take the incoming value, or edit your own.
With
--json, the CLI never prompts. A merge that stops on conflicts exits with the error code MERGE_CONFLICTS, the merge ID, and the conflicts. Add --yes to keep the current Branch’s values instead.
Once you resolve the conflicts, the CLI waits for the merge to finish and reports whether it completed or failed. If the merge is still running when the CLI stops waiting, run fimo merge <from> --resume to keep following it. Resuming never submits your answers twice.
When you resolve code conflicts, the merge also carries over non-conflicting file additions, deletions, and renames from the source Branch. A new file does not need to exist on the target Branch first. A renamed file moves rather than being copied: the target gets the new path and loses the old one. Changes made only on the target Branch are preserved.
Review agent proposals
Ask an agent for several alternatives and keep each as a named proposal. Proposals appear in the Branch picker with their own Preview and changes. Internal work stays out of the picker, even when it has been saved or given more time. Visibility and retention are separate: extending a deadline does not show the work. Open the proposal links from Studio, Slack, or an agent report. Access requires permission to the site, and the Preview shows the Branch’s current state. You can return later and ask the agent to refine or merge one proposal. Choosing one leaves the others available until you explicitly reject or discard them. A review request refers to saved work. If the proposal or its target changes, request a new review or open the current changes from the Branch picker before merging. Keeping a proposal does not publish it or give it an automatic expiry. Use Delete to discard an alternative you no longer need. To create a Branch from a proposal, merge the proposal first. The CLI lists the underlying Branch names; Studio shows the proposal names. Deleting a Branch also discards its open work sessions and preserves their conversation history. If a session operation is running, wait for it to finish and retry the deletion. Once deletion is accepted, the Branch disappears and its backing resources are cleaned up in the background. Temporary cleanup failures are retried automatically. The same Branch name remains reserved until cleanup finishes.Older unfinished tasks
The multi-chat update keeps your existing conversations and saved work sessions. Unfinished tasks from the earlier task system that were never saved as work sessions are discarded, and their temporary environments are removed. Historical reviews remain readable and show the discarded outcome. Your published site and regular Branches are preserved.Group Branches into Environments
Every site has Preview and Production. Preview contains Branches that are not assigned to a custom Environment. Production represents the published site. If your plan includes custom Environments, you can group Branches by exact names or trailing wildcard patterns:What’s next
Preview vs production
Keep review links separate from the public site.
Launch checklist
Move from reviewed Preview to a verified launch.
Version history
Save and restore site states.