Merge requests and approvals
Merge requests in Forge cover review, approvals and merging. They belong to the same Orbit project as the work they implement.
Open and review
Section titled “Open and review”- Open a merge request from a branch (or from a fork’s branch to its upstream).
- The diff has line numbers; large requests load one file at a time. Leave line threads and general comments, reply, and resolve a thread. Resolved and outdated filters are available.
- Assign reviewers (one person at a time, or one member of a group) and re-request a review. A reviewer can mark changes requested, which blocks merging until it is cleared.
- Merging can additionally require that all threads are resolved.
- Suggestions in comments can be applied as commits, in batches.
- Keys of work items in the branch name, commit messages or the request link it to the project’s work items, and a merge request can also be linked to a work item explicitly.
Approvals
Section titled “Approvals”Approval rules decide who must approve:
| Setting | Options |
|---|---|
| Approvers | Any eligible member, specific people, or Orbit groups |
| Required count | 0 to 25 |
| Target branch | Optional: a rule can apply only to one target branch |
| Author and committer | Optionally restrict them from approving their own change |
| New commits | Remove all approvals, remove those for code-owner files, or keep them |
| CODEOWNERS | Sections, optional sections with counts; code-owner approval can be required for the default branch |
A merge is allowed only when the rules are met, no change request is open, threads are resolved if you require it, and the pipeline of the exact committed CI configuration has passed. Merge-request-level overrides of rules are not included.
Merging
Section titled “Merging”- Merge methods: merge commit, semi-linear and fast-forward, with a squash policy (never, allow, encourage or require) and editable commit messages.
- Conflicts are listed; a linear server-side rebase is available.
- Auto-merge merges as the person who set it once the source pipeline succeeds and every check passes. New commits, a failed pipeline or lost permission cancel it.
- Merged-results pipelines (opt-in) run on the merged result of the source and target.
- Merge trains hold up to 20 requests per target branch. Each is tested on top of the requests ahead of it and merged to exactly its tested commit. A failed car is dropped and the rest are rebuilt.
- Stacked merge requests declare dependencies; Forge retargets them automatically when the one below merges.
- Merge requests from forks run on the fork’s own branch pipeline: fork code never runs in the upstream with its CI secrets. Fork requests cannot join merge trains.
Work items and deployments
Section titled “Work items and deployments”Forge applies the project’s Orbit rules to merge requests: transition rules, closing patterns and smart commits are applied through the work item’s workflow, acting as the person involved. Deployments are recorded on the work items whose commits they shipped.