Integrate reviewed branch changes into the canonical branch — visually, in the browser.
Once a branch is reviewed, you merge it into the canonical branch directly in IOModel Studio. Merge is built on the branch and commit model: review the visual diff, preview the merged result, then merge in the browser — synced to a GitHub or GitLab merge request when the repository is connected.
How landing works depends on the target branch type:
| Target | How changes land |
|---|---|
| Standard | Any editor can merge (including the author). No merge request required. |
| Protected | Open a merge request. Another editor must merge it — you cannot merge your own. Git-sync merge requests can be merged by any editor. |
| Collab | Commit directly on the room. Publish outward by merging (or requesting review) into Standard or Protected. |
The merge flow
Finish and commit
Commit all work on the branch with clear messages so the diff reflects a stable state.
Review the visual diff
Open the branch diff and confirm the added, removed, and changed objects, links, and specs are exactly what you intend.
Preview the merged result
Studio shows the combined state before you commit to it, so there are no surprises after merging.
Merge on approval
What gets merged
| Content | Merged |
|---|---|
| Model objects and links | Added, removed, and modified, on the diagram |
| Specifications | MDX page content and structure, including _attachments/ |
| Attachments | Images, OpenAPI, ERD, workflow, source-text, and other declared files |
Canonical state
| Concept | Role |
|---|---|
| Default branch | The canonical, shippable state |
| Reviewed branch | A proposed change, validated via visual diff |
| Merge | Integrating the reviewed branch into the target |
Synced with git
When a project is connected with Git sync, a merge in Studio is mirrored to the linked repository — the same change can land as a GitHub pull request or GitLab merge request.
Force merge
Bypassing model validation (force) is an admin action and is recorded on
the merge. Use it only when you intend to land an invalid model.
Keep branches short-lived. The longer a branch lives, the more its base moves and the larger the diff to review before merge.
Last updated on