Merge Request Settings
Merge Request Approvers
This feature is available in the Enterprise version, as well as on gitflic.ru
Merge request approvers are project members whose approvals are required to merge a request into a specified branch. The requirement for approvals from approvers and code owners helps maintain a high level of product quality.
To create an approval rule for merge requests, click "Add Rule" and specify:
- A name for the rule. It will be displayed in the table with all rules.
- Approvers whose approvals are required. Approvers can be users with the Developer or higher role.
- In the "Target Branch" selector, choose an existing project branch for which this rule will apply.
- In the "Minimum number of approvals" field, specify the number of approvals required to make the merge request eligible for merging. This number can be less than the total number of approvers.
After clicking the "Confirm" button, the rule will be created. To edit or delete an existing rule, use the corresponding buttons.
Merge Request Settings
This feature is available in the Enterprise version, as well as on gitflic.ru
For more flexible merge request management, there are settings that allow you to define the following behaviors:
- Allow overriding approvers and approvals required for a merge request – allows changing approvers and approvals in the merge request.
- Remove all approvals in a merge request when a new commit is pushed to the source branch – using this setting together with merge request approvers prevents merging changes that have not been approved by the responsible parties.
- Prohibit the author from approving their own merge request – the user who created the merge request cannot approve it.
- Prohibit developers from approving their own merge request – users who have pushed at least one commit to the source branch cannot approve the request.
- Check the status of the latest pipeline when merging a request – merging will only be possible if the specified pipeline types exist for the latest commit in the source branch and have completed with Success or Warning status.
- Allow editing a merged request – allows changing the title, description, and other information of already merged requests.
- Remove all approvals in a merge request when the target branch is changed – using this setting together with merge request approvers prevents merging after the target branch has been changed.
Applying Approval Rules and Merge Request Settings
Each request has a set of requirements that must be met for merging. Approvers and merge request settings also affect this list of requirements:
- When an approval rule is active, merging is not possible until the required number of approvers have approved the request. If there are multiple rules for one branch, each must be satisfied.
- Successful completion of both the regular and merge result pipelines may also be a mandatory condition for merging changes.
Auto-Merge Rules
To enable automatic merging, you need to turn on the option and specify a set of conditions that must be met for merging to complete. The following conditions can be selected as mandatory:
- No conflicts
- All discussions resolved
- Approvals from approvers
- Successful pipeline
The pipeline success check is performed if the Check the status of the latest pipeline when merging a request option is enabled in merge request settings. If Merge Result Pipeline is enabled in CI/CD settings, this type of pipeline will also be checked.
Once the automatic merge method is selected, manual merging becomes impossible. Automatic merging can be enabled in two ways:
-
Click the corresponding button in a specific request. After enabling automatic merging, the user who selected this method will be shown in this field. To prevent accidental merges, automatic merging cannot be enabled for a request that is already eligible for manual merging.
-
In branch protection rules, you can enable auto-merge by default for specified branches. In this case, the author of the merge request will be listed as the initiator of the auto-merge.
Merge Methods
This feature is available in the Enterprise version, as well as on gitflic.ru
The selected merge method determines how changes are applied to the target branch. The following merge methods are available:
- Create a merge commit – Selected by default. Each merge creates a merge commit.
- Create a merge commit with semi-linear history – Each merge creates a merge commit. If merging is not possible due to the source branch being outdated relative to the target, you will be prompted to rebase the source branch onto the target.
- Fast-forward merge – No merge commit will be created. If merging is not possible due to the source branch being outdated relative to the target, you will be prompted to rebase the source branch onto the target.
Conflict resolution via the interface is not available when using the semi-linear history or fast-forward merge methods.
Squash Commit Rules
The squash commit rule setting allows you to specify the default state of the feature when creating a merge request. The following options are available:
- Disabled – Squash merge will be unavailable, and the checkbox will be hidden.
- Allowed – Selected by default. Squash merge is available, the checkbox is visible and not selected by default.
- Recommended – Squash merge is available, the checkbox is visible and selected by default.
- Required – Squash merge is available, the checkbox is visible and always selected, with no option to disable it.
Merge Request Templates
Template message settings allow you to set informative commit messages that are created after merging – both merge commit and squash commit. In addition, templates can be used to set a default description for merge requests.
For more flexible template configuration, a number of predefined variables are supported:
| Variable | Description |
|---|---|
%{title} |
Merge request title |
%{description} |
Merge request description |
%{source_branch} |
Source branch name |
%{target_branch} |
Target branch name |
%{url} |
Merge request URL |
%{first_commit} |
First commit in the source branch after merge-base |
%{all_commits} |
List of all commits in the source branch |
%{merged_by} |
Merge request author |
%{co_authored_by} |
Co-authors – users who made commits to the source branch |
%{approved_by} |
List of approvers assigned when creating the merge request |
The
%{description}variable is not supported in the merge request description template.
The Allow editing template messages during merge toggle allows you to prohibit editing the template message for the merge commit or squash commit during merging.
Applying Merge Request Templates
The description template will be automatically applied when creating a merge request. You can change the description both during creation and afterwards using the Edit function.
After clicking the Merge button, a Create Commit window will appear, where you can edit the commit message text. Instead of the variables used in the template, their values will be shown. The option to edit the squash commit message will only appear if the squash merge option was selected in the merge request.
If you change the squash commit message to empty, a commit with the default text – the source branch name – will be created after merging.
Merge Request Settings for Teams and Companies
In team and company settings, you can also configure merge requests:
- The specified settings can be applied to existing team or company projects using the Apply Settings function.
- The Apply merge request approval rules to new team projects toggle allows you to create projects owned by the team or company with existing rules already in place.
Automated translation!
This page was translated using automatic translation tools. The text may contain inaccuracies.