Code Review

GitBlixt gives you everything you need to review changes before they merge: a diff viewer with unified and side-by-side modes, inline comments on specific lines, reviewers, approvals, and approval rules that can gate merging.

Reviewing the Diff

Open a pull request and select the Files changed tab. Each changed file is listed in a file tree with per-file +/- stats and a status marker (new, deleted, renamed, or modified). Click a file header to collapse or expand it, or use the toolbar button to toggle all files at once.

Switch between two diff layouts with the Unified and Split tabs:

• Unified — additions and deletions interleaved in a single column.
• Split — side-by-side, with old content on the left and new on the right.

Inline Comments

Hover over any line in the diff (added, removed, or context) and click the + button that appears in the gutter to start a comment on that exact line. Your comment is attached to the file path and line number, and appears as a threaded block directly beneath the line.

Inline comments are scoped to the line they were left on, so subsequent replies on the same line group together into one discussion. You must be signed in to comment.

Conversation

The Conversation tab holds the pull request description, a summary of the commits, merge checks, and the general discussion thread. Use the comment box at the bottom to leave a general (non-line-specific) comment. Commits pushed to the source branch appear inline in the timeline as system events.

Reviewers

Add reviewers from the Reviewers section in the sidebar (the cog icon opens a list of repository collaborators and the owner). Each reviewer carries a state:

Request changes only works if you are already a reviewer on the pull request.

Approvals

Anyone with access can approve an open pull request with the Approve button. Approving also flips your reviewer state to approved; you can withdraw it later with Revoke approval, which resets your reviewer state to unreviewed. You can only approve a pull request once.

The sidebar shows a running count of approvals and the status of each approval rule.

Approval Rules

Approval rules let you require a minimum number of approvals before a pull request can merge. Each rule has:

• Name — a label for the rule.
• Approvals required — how many approvals must be collected (at least one).
• Eligible users — an optional list of users whose approvals count toward the rule. If you leave it empty, any approval on the pull request counts.

A rule is satisfied once the number of approvals from eligible users (or any approvals, when no users are specified) meets or exceeds its required count.

How Approvals Gate Merging

Approval rules feed into the pull request's merge checks, shown on the Conversation tab. A pull request is considered approved only when every rule is satisfied (a repository with no rules is approved by default). If a check is failing, the merge panel warns you before you proceed. When you are ready, choose a merge strategy — Merge commit, Squash and merge, or Fast-forward — and optionally delete the source branch after merging.

Viewing a Single Commit

Click any commit (from the pull request's Commits tab, the file history, or elsewhere) to open its page at /<namespace>/<repo>/-/commit/<sha>. The commit page shows the message, author, relative commit time, full SHA (with a copy button), the associated CI pipeline status, and a per-file diff with addition and deletion counts.

Blame and File History

When viewing a file in the repository browser, two buttons in the file header help you trace its evolution:

• Blame — opens /<namespace>/<repo>/-/blame/<ref>/<path> to show which commit last changed each line.
• History — opens /<namespace>/<repo>/-/history/<ref>/<path> to list the commits that touched the file.

From either view you can click through to an individual commit to see its full diff.