Skip to main content
Requests let your team review important actions before they happen. Instead of merging a branch or deploying a release on the spot, you open a request; teammates review the proposed change, discuss it, and approve or reject it. Once the requirements are met, the request can be completed and the action goes through. Whether an action needs a request depends on your project’s settings - see Approval requirements below.

​
The Requests page

Open Requests from the sidebar rail. A badge on the icon shows how many requests are pending. Filter the list by Pending, Completed, Cancelled, or Rejected, or search by name.
Requests page showing a filtered list of pending requests and an open request with its discussion timeline

The Requests page with pending requests

Requests cover five kinds of action: Merge requests are opened from the Review page - see Review & save. Deploy requests open automatically when you deploy a release to an environment marked “requires review” - see Releases.

​
Inside a request

Selecting a request opens its detail pane. The header shows the essentials: Author, Branch, Type, Status, Approvals (for example “1/2 approval groups”), and when it was opened. For merge requests you can also browse the proposed file changes, shown as a diff against main.

​
Discussion

The Discussion section is a timeline of everything that happened on the request, oldest first: who opened it, pushed changes, approved, withdrew approval, rejected it, completed it, or cancelled it - along with any comments. The composer at the bottom offers four actions: Comment, Approve, Reject, and Withdraw (which takes back your earlier approval).
Authors can’t approve or reject their own request. Every request needs a second pair of eyes.

​
Completing a request

The completion block at the bottom of the pane tells you what’s left: You can abandon a request at any time with Cancel request. Cancelling leaves the branch and its commits intact - only the request is closed.

​
Approval requirements

Project settings define what a request needs before it can be completed:
  • No approvals: actions go through directly, without a request.
  • Request without approvals: a request is created for visibility, and anyone can complete it.
  • Any one group: one approval from any of the project’s approval groups is enough.
  • One per group: each approval group must provide at least one approval.
Environments add their own layer: marking an environment as “requires review” means every deployment to it opens a deploy request, regardless of how it was triggered.
Pair approval requirements with a protected main branch. Contributors then save their work to branches, and every change reaches main through a reviewed merge request. Pre-flight checks on the Review page and tests from Quality Control give reviewers the signal they need to approve with confidence.