Merge Requests

A merge request (also called a pull request in the UI) proposes merging the commits on a source branch into a target branch. It collects the commits, the file diff, discussion, reviews, and CI results in one place, and gates the merge behind any configured checks.

Opening a Merge Request

From a repository, go to Pull Requests → New pull request (/-/merge_requests/new). Then:

1. Pick the base (target) and compare (source) branches. GitBlixt shows a live comparison: commit count, files changed, additions/deletions, and a badge indicating whether the branches can merge cleanly or have conflicts.
2. Enter a title (required) and an optional Markdown description. The description editor supports a preview tab and drag-and-drop file attachments.
3. Optionally check Mark as draft, assign a user, and apply labels from the sidebar.
4. Click Create pull request.

If a comparison shows no commits between the branches, or the same branch is chosen for both sides, GitBlixt tells you instead of creating an empty request. Creating a merge request automatically triggers a CI pipeline for the source branch.

Cross-fork merge requests

If the repository is a fork, the new-MR form offers a toggle to open the request against the upstream repository instead. The source branch comes from your fork; on merge, GitBlixt fetches that branch into the upstream repository before merging.

Templates

Repositories can define merge request templates (name, optional description, and Markdown content) to pre-fill the description with a consistent checklist or structure.

Draft Merge Requests

Marking a request as a draft prepends Draft: to the title and shows a Draft badge. Use drafts to signal that work is still in progress and not yet ready to merge.

Reviewing the Merge Request

The merge request page is organized into tabs:

• Conversation — the description, a timeline of pushed-commit events and comments, the merge checks, approval controls, and the merge action.
• Commits — every commit on the source branch, each linking to its full commit view and showing its pipeline status.
• Checks — the latest CI pipeline for the source branch and its individual jobs.
• Files changed — the full diff, viewable unified or side-by-side, with collapsible files.

Reviewers, approvals, and inline (per-line) review comments are covered in detail on the Code Review page.

Merge Checks

Before a request can merge, GitBlixt evaluates any branch rules whose pattern matches the target branch. When multiple rules match, a check is required if any matching rule requires it, and the highest minimum-approval count wins. With no matching rules, no checks block the merge. The possible checks are:

Each check reports pass, fail, or pending. A request is blocked only while a check is failing; pending checks do not block. If you attempt to merge while a check fails, the merge is rejected with the failing reasons.

Merging

When a request is open and you have merge permission for the target branch, the Conversation tab offers three strategies:

• Merge commit — creates a merge commit joining the two branches (the default).
• Squash and merge — combines the source branch's commits into a single commit on the target.
• Fast-forward — moves the target branch forward to the source commit with no merge commit.

You can also tick Delete branch to remove the source branch after a successful merge. Merging records the merge time, triggers a pipeline on the target branch, syncs any push mirrors, and cleans up preview deployments for the request. After a merge you can still delete the source branch from the post-merge panel.

Auto-merge

A merge request can be set to merge automatically once the pipeline for its source branch succeeds (merge_when_pipeline_succeeds). When a pipeline finishes successfully, GitBlixt merges any open requests on that branch that have auto-merge enabled, using their stored strategy. This is most useful via the API.

States

A merge request is in one of three states: opened, closed, or merged. Merging moves a request to merged. Closing a request without merging (and reopening a closed one) is done through the GitLab-compatible API by updating the request's state — see the API documentation.

Browsing Merge Requests

The Pull Requests list (/-/merge_requests) shows each request's title, author, source → target branches, labels, and state. Filter by state (Opened, Closed, Merged, or All) and by label.