Merge requests | GitLab Docs Skip to main content Go to GitLab Docs homepage What's new? What's new? Get free trial Toggle menu * Use GitLab * GitLab Duo * GitLab Orbit * Extend * Install * Administer * Subscribe * Contribute * Solutions Getting started Tutorials Manage your organization Organize work with projects Plan and track work Manage authentication and authorization Use Git Manage your code Getting started Repositories Merge requests Commits Changes Create merge requests Reviewing and managing merge requests Workflows Export merge requests to CSV Reports Troubleshooting Remote development Use CI/CD to build your application Secure your application Deploy and release your application Manage your infrastructure Monitor your application Analyze GitLab usage Release notes Feature support Find your GitLab version * GitLab Docs / * Use GitLab / * Manage your code / * Merge requests Help us learn about your current experience with the documentation. Take the survey . Merge requests * Tier : Free, Premium, Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated Merge requests provide a central location for your team to review code, have discussions, and track code changes. To help describe why a change was made, link a merge request to an issue and automatically close the issue when the merge request merges. Merge requests help ensure subject matter experts review your proposed changes and your organization s security requirements are met. When you create your merge request early in the development process, your team has time to catch bugs and code quality problems. When viewing a merge request, you see: * A description of the request. * Code changes and inline code reviews. * Information about CI/CD pipelines. * Mergeability reports. * Comments. * The list of commits. Assignees and reviewers A merge request has two roles: * Assignee : Owns the merge request and is responsible for its progress. The assignee is usually the author. * Reviewer : Reviews the changes and provides feedback. A reviewer can request changes or, if eligible, approve the merge request. Your project s approval rules and settings determine who can approve merge requests. For more information, see assign an assignee and request a reviewer . Create a merge request Learn the different ways to create a merge request . Use merge request templates When you create a merge request, GitLab checks for the existence of a description template to add data to your merge request. GitLab checks these locations in order from 1 to 5, and applies the first template found to your merge request: Name Project UI setting Group default.md Instance default.md Project default.md No template Standard commit message 1 2 3 4 5 Commit message with an issue closing pattern like Closes #1234 1 2 3 4 5 * Branch name prefixed with an issue ID , like 1234-example 1 * 2 * 3 * 4 * 5 * Items marked with an asterisk (*) also append an issue closing pattern . View merge requests You can view merge requests for your project, group, or yourself. For yourself To view all merge requests that require your participation, use one of the following: * Keyboard shortcut: Shift + M * In the left sidebar, select Merge requests . * In the top bar, select Search or go to . From the dropdown list, select Merge requests . For a project To view all merge requests for a project: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests . Or, to use a keyboard shortcut, press g + m . For all projects in a group To view merge requests for all projects in a group: * In the top bar, select Search or go to and find your group. * In the left sidebar, select Code > Merge requests . If your group contains subgroups, this view also displays merge requests from the subgroup projects. For a file When you view a file in your repository, GitLab shows a badge with the number of open merge requests that target the current branch and modify the file. The badge helps you identify files that have pending changes. The availability of this feature is controlled by a feature flag. For more information, see view open merge requests for a file . To view the open merge requests for a file: * In the top bar, select Search or go to and find your project. * Go to the file you want to view. * In the upper right of the screen, next to the filename, look for the green badge with the number of Open merge requests. * Select the badge to see a list of open merge requests created in the past 30 days. * Select any merge request in the list to go to that merge request. Subscribe to an RSS feed of the merge request list To subscribe to an RSS feed of a project s merge request list: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests . * In the upper-right corner, select Actions ( ) > Subscribe to RSS feed . To subscribe to an RSS feed of a group s merge request list, follow the same steps. In the top bar, select Search or go to and find your group instead of a project. The feed URL contains a feed token that authenticates you as the feed reader. Filter the list of merge requests History * Filter by merged by introduced in GitLab 16.9. Available only when the feature flag mr_merge_user_filter is enabled. * Filter by merged by generally available in GitLab 17.0. Feature flag mr_merge_user_filter removed. * Filter by merged before and merged after introduced in GitLab 18.6. To filter the list of merge requests: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests . * Above the list of merge requests, select Search or filter results . * From the dropdown list, select the attribute you want to filter by. Some examples: * By environment or deployment date . * ID : Enter filter #30 to return only merge request 30. * User filters: * Approved by , for merge requests already approved by a user. Premium and Ultimate only. * Approver , for merge requests that this user is eligible to approve. (For more information, read about Code Owners ). Premium and Ultimate only. * Merged by , for merge requests merged by this user. * Reviewer , for merge requests reviewed by this user. * Select or type the operator to use for filtering the attribute. The following operators are available: * = : Is * != : Is not * Enter the text to filter the attribute by. You can filter some attributes by None or Any . * Repeat this process to filter by more attributes, joined by a logical AND . * Select a Sort direction , either for descending order, or for ascending order. By environment or deployment date To filter merge requests by deployment data, such as the environment or a date, you can type (or select from the dropdown list) the following: * Environment * Deployed before * Deployed after Projects that use a fast-forward merge method do not return results, because this method does not create a merge commit. To filter by an environment, select an option from the dropdown list of available environments. To filter by Deployed before or Deployed after , enter a deploy date manually: * The date refers to when the deployment to an environment (triggered by the merge commit) completed successfully. * Use the format YYYY-MM-DD . To specify both a date and time, use double quotes ( "YYYY-MM-DD HH:MM" ). Add changes to a merge request If you have permission to add changes to a merge request, you can do so in several ways. The method to use depends on the complexity of your change, and whether you need access to a development environment: * Edit changes in the Web IDE in your browser. Press . (period) on any project page in GitLab to open the Web IDE. Use this browser-based method to edit multiple files, or if you are not comfortable with Git commands. You cannot run tests from the Web IDE. * Edit changes in Ona , if you need a full-featured environment to both edit files and run tests afterward. Ona supports the GitLab Development Kit (GDK). To use Ona, you must turn on Ona in your user account. * Push changes from the command line , if you are familiar with Git and the command line. Assign a user to a merge request To assign the merge request to a user, use the /assign @user quick action in a text area in a merge request, or: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests and find your merge request. * In the right sidebar, in the Assignees section, select Edit . * Search for the user you want to assign, and select the user. On GitLab Free, you can assign one user per merge request. On GitLab Premium and GitLab Ultimate, you can assign multiple users: GitLab adds the merge request to the user s Assigned merge requests page. Participants Participants are users who interacted with a merge request. For information about viewing participants, see participants . Merge a merge request During the merge request review process, reviewers provide feedback on your changes. When a reviewer is satisfied with the changes, they can set the merge request to auto-merge , even if some merge checks are failing. After all merge checks pass, the merge request is automatically merged, without further action from you. Default merge permissions: * The default branch, typically main , is protected. * Only Maintainers and higher roles can merge into the default branch. * Developers can merge any merge request that targets a non-protected branch. To determine if you have permission to merge a specific merge request, GitLab checks: * Your role in the project. For example, Developer, Maintainer, or Owner. * The branch protections of the target branch. Close a merge request If you decide to permanently stop work on a merge request, close it rather than deleting it . Prerequisites: * You must be the author or an assignee of the merge request, or have the Developer, Maintainer, or Owner role for the project. To close a merge request in the project: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests and find your merge request. * Scroll to the comment box at the bottom of the page. * After the comment box, select Close merge request . GitLab closes the merge request, but preserves records of the merge request, its comments, and any associated pipelines. Delete the source branch History * Option to delete the source branch from a closed merge request introduced in GitLab 19.1. To delete the source branch for a merge request: * When you create a merge request, by selecting Delete source branch when merge request accepted . * When you merge a merge request, if you have the Maintainer role, by selecting Delete source branch . * When you close a merge request without merging, by selecting Delete source branch . An administrator can make this option the default in the project s settings. For merge requests from forks, GitLab reads the Delete source branch default from the fork, not the target project. The user who sets auto-merge or merges the merge request performs the branch deletion. If that user lacks the correct role, such as in a forked project, the source branch deletion fails. Update merge requests when target branch merges * Tier : Free, Premium, Ultimate * Offering : GitLab.com, GitLab Self-Managed, GitLab Dedicated Merge requests are often chained together, with one merge request that depends on the code added or changed in another merge request. To support small, individual merge requests, GitLab can update up to four open merge requests when their target branch merges into main . For example: * Merge request 1: merge feature-alpha into main . * Merge request 2: merge feature-beta into feature-alpha . If these merge requests are open at the same time, and merge request 1 ( feature-alpha ) merges into main , GitLab updates the destination of merge request 2 from feature-alpha to main . Merge requests with interconnected content updates are usually handled in one of these ways: * Merge request 1 merges into main first. Merge request 2 is then retargeted to main . * Merge request 2 merges into feature-alpha . The updated merge request 1, which now contains the contents of feature-alpha and feature-beta , merges into main . This feature works only when a merge request is merged. Selecting Remove source branch after merging does not retarget open merge requests. This improvement is proposed as a follow-up . Merge request workflows For a software developer who works in a team: * You check out a new branch, and submit your changes through a merge request. * You gather feedback from your team. * You optimize your code with code quality reports . * You verify your changes with unit test reports in GitLab CI/CD. * You avoid dependencies with licenses that are not compatible with your project, with license approval policies . * You request the approval from your manager. * Your manager: * Pushes a commit with their final review. * Approves the merge request. * Sets it to auto-merge (formerly Merge when pipeline succeeds ). * Your changes get deployed to production with manual jobs for GitLab CI/CD. * Your implementation ships to your customer. For a web developer who writes a webpage for your company s website: * You check out a new branch and submit a new page through a merge request. * You gather feedback from your reviewers. * You preview your changes with review apps . * You ask your web designers to implement their changes. * You request the approval from your manager. * After approval, GitLab: * Squashes the commits. * Merges the commit. * Deploys the changes to staging with GitLab Pages . * Your production team cherry-picks the merge commit into production. Filter activity in a merge request To understand the history of a merge request, filter its activity feed to show you only the items that are relevant to you. * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests . * Select a merge request. * Scroll to Activity . * On the right side of the page, select Activity filter to show the filter options. If you ve already selected filter options, this field shows a summary of your choices, like Activity + 5 more . * Select the types of activity you want to see. Options include: * Assignees & Reviewers * Approvals * Comments (from bots) * Comments (from users) * Commits & branches * Edits * Labels * Lock status * Mentions * Merge request status * Tracking * Optional. Select Sort ( ) to reverse the sort order. Your selection persists across all merge requests. You can also change the sort order with the sort button on the right. Manage comment threads Discussions in a merge request include single comments and threads of comments. Open (unresolved) threads block the merge of a merge request, but single comments do not. When a discussion in a thread is finished, resolve the thread to collapse its display. If a comment thread is important but should not block the merge request, move it to an issue to continue the discussion. Expand all threads GitLab shows the number of open threads in the upper-right corner of a merge request. This merge request has three open threads: To see all comments in the collapsed threads, expand the threads: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests and find your merge request. * In the merge request, in the upper right, find the Open threads dropdown list, and select Thread options ( ). * Select Show all comments . Move open threads to an issue To move open threads to a new issue, and unblock a merge request: Move one thread If you have one specific open thread in a merge request, you can create an issue to resolve it separately: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests and find your merge request. * In the merge request, find the thread you want to move. * Below the last reply to the thread, next to Resolve thread , select Create issue to resolve thread ( ). * Fill out the fields in the new issue, and select Create issue . GitLab marks the thread as resolved, and adds a link from the merge request to the new issue. Move all open threads If you have multiple open threads in a merge request, you can create an issue to resolve them separately: * In the top bar, select Search or go to and find your project. * In the left sidebar, select Code > Merge requests and find your merge request. * In the merge request, in the upper right, find the Open threads dropdown list, and select Thread options ( ). * Select Resolve all with new issue . * Fill out the fields in the new issue, and select Create issue . GitLab marks all threads as resolved, and adds a link from the merge request to the new issue. Prevent merge unless all threads are resolved You can prevent merge requests from merging while threads remain open. When you turn on this setting, the Open threads counter in a merge request appears in orange while at least one thread remains open. * In the top bar, select Search or go to and find your project. * In the left sidebar, select Settings > Merge requests . * In the Merge checks section, select the All threads must be resolved checkbox. * Select Save changes . Automatically resolve threads when they become outdated You can configure merge requests to automatically resolve threads when a new push changes the lines those threads describe. * In the top bar, select Search or go to and find your project. * In the left sidebar, select Settings > Merge requests . * In the Merge options section, select Automatically resolve merge request diff threads when they become outdated . * Select Save changes . Threads are