Merge Requests

To configure MRs, you can choose Settings > Policy Settings > Merge Requests on the repository details page.

Merge Requests applies to merge MRs. MRs can be merged only when all configured MR conditions are met. You can select Score or Approval for Merge Mechanism.

The settings take effect only for the repository configured.

All repository members can view this page. For details about whether a repository member has repository setting permissions, refer to the Permissions page.

Merge Mechanism

Score: Code review is included. Based on scoring, the minimum merging score can be set and the score ranges from 0 to 5. The code can be merged only when the score and mandatory review meet pass conditions. When selecting the scoring mechanism, you need to set the minimum score.
Approval: Code review and merge approval are included. Code can be merged only after the number of reviewers reaches gate requirements. You are advised to configure branch policies when you select the approval mechanism.

By default, Approval is used. You can manually switch to Score.

After the merge mechanism is switched, the workflows of the MRs are changed. However, the early created MRs retain the previous merge mechanism.

Merge Conditions

**Table 1** Parameters
Parameter	Description
Merge after all reviews are resolved.	After this parameter is selected, if Must resolve is selected as the review comment, a message Review comment gate: failed is displayed and the Merge button is unavailable. If it is a common review comment, the Resolved button does not exist, the MR is not intercepted by the merge condition.
Must be associated with CodeArts Req	Associate only one ticket number: If this parameter is selected, one MR can be associated with only one ticket number. All E2E ticket numbers pass verification: If this parameter is selected, all associated E2E ticket numbers must pass the verification. Branches to configure the MR policy: Multiple branches can be added. You can manually enter wildcard characters and press. Press Enter, for example, *-stable or production/*.

MR Settings

**Table 2** Parameters
Parameter	Description
Do not merge your own requests	After this parameter is selected, the Merge button is unavailable when you view the MRs created by yourself. You need to ask the person who has the permission to merge the MRs.
Do not approve your own requests	If you select this parameter, the Approve button is dimmed and you cannot approve your own MRs. You need to ask another person with the approve permission to approve your MRs.
Do not review your own requests	If you select this parameter, the Review button is dimmed and you cannot review your own MRs. You need to ask another person with the approve permission to approve your MRs.
A repo administrator can forcibly merge code	An administrator can forcibly merge code even if the merging conditions are not met.
Continue with code review and comment after requests are merged	After this parameter is selected, you can continue to review and comment on the code that has been merged the MR.
Mark the automatically merged MRs as Closed (If all commits in the B MR are included in the A MR, the B MR is automatically merged after the A MR is merged. By default, the B MR is marked as merged. You can use this parameter to mark the B MR as closed.)	If this parameter is not selected, MRs that are automatically merged are marked as merged. If this parameter is selected, MRs that are automatically merged are marked as closed.
Cannot re-open a Closed MR.	If this option is selected, the branch merge request cannot be set back to Open after it is closed. Re-open in the upper right corner is hidden. This parameter is used for process control to prevent review history from being tampered with.
Delete source branch by default after the MR is merged	After the merging, the source branch is deleted. A protected source branch cannot be deleted. This setting does not take effect for historical MRs. Therefore, you do not need to worry about branch loss.
Do not Squash	After this parameter is selected, the Squash button is unavailable, and the entry for using this button is unavailable in the MR.
Enable Squash merge for new MRs	Squash merge means that when merging two branches, Git squashes all changes on the merged branch into one and appends them to the end of the current branch as merge commit, which simplifies the branch. The only difference between squash merge and common merge lies in the commitment history. For common merge, the merge commitment on the current branch usually has two commitment records, while squash merge has only one commitment record.

Merge Method

**Table 3** Parameters
Parameter	Description
Merge commit	If this parameter is selected, a merge commit is created for every merge, and merging is allowed as long as there are no conflicts. That is, no matter whether the baseline node is the latest node, the baseline node can be merged if there is no conflict. Do not generate Merge nodes during Squash merge: If this parameter is selected, no merge node is generated during the squash merging. Use MR merger to generate Merge Commit: If this parameter is selected, the commit information is recorded. Use MR creator to generate Merge Commit: If this parameter is selected, the commit information is recorded.
Merge commit with semi-linear history	If this parameter is selected, a merge commit is recorded for each merge operation. However, different from Merge commit, the commitment must be performed based on the latest commit node of the target branch. Otherwise, the system prompts the developer to perform the rebase operation. In this merging mode, if the MR can be correctly constructed, the target branch can be correctly constructed after the merge is complete.
Fast-forward	If this parameter is selected, no merge commits are created and all merges are fast-forwarded, which means that merging is only allowed if the branch could be fast-forwarded. When fast-forward merge is not possible, the user is given the option to rebase.

Configure Branch Policy

Click Create Branch Policy to set a merge policy for a specified branch or all branches in the repository.

Currently, branch policies can be set only for the Approval mechanism.

The following is an example of the branch policy priority:

Assume that there are policies A and B in the repository and their branches are the same. The system uses the latest branch policy by default.
Assume that there are policies A and B in the repository. Branch a and branch b are configured for policy A, and branch a is also configured for policy B. When a merge request whose target branch is branch a is committed, the system uses policy B by default.

If no branch policy is set in the approval mechanism, the default branch policy is used when a merge request is committed. The branch policy can be edited and viewed but cannot be deleted. The policy configuration is as follows:

Branches: *. By default, all branches are used and cannot be modified.
Reviewers Required: The default value is 0.
Approvals Required: The default value is 0.
Reset approval gate: This option is selected by default.
Reset review gate: This option is selected by default.
Add approvers/reviewers only from the following ones: This option is not selected by default.
Enable pipeline gate: This option is not selected by default.
Mergers: This parameter is left blank by default.
Approvers: This parameter is left blank by default.
Reviewer: This parameter is left blank by default.

**Table 4** Parameters
Parameter	Description
Branches	Set policies for all branches or a branch.
Reviewers Required	Set Reviewers Required. When the number of reviewer who give pass meets the Reviewers Required, the gate is passed. 0 indicates that the review gate is optional. However, if an MR is rejected by a reviewer, it fails the gate.
Approvals Required	Set Approvals Required. When the number of approvals who give pass meets the Approvals Required, the gate is passed. 0 indicates that the approval gate is optional. However, if an MR is rejected by an approver, it fails the gate.
Reset approval gate	When code is re-pushed to the source branch of an MR.
Reset review gate	When code is re-pushed to the source branch of an MR.
Add approvers/reviewers only from the following ones	If this option is selected, you can configure the list of New Approvers and New Reviewers. If you want to add additional members, you can only add members from the lists.
Enable pipeline gate	If this option is selected, before the merge, you need to pass all pipeline gates. This rule integrates the CI into the code development process.
Mergers	The list of mandatory mergers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.
Approvers	The list of mandatory approvers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.
Reviewer	The list of mandatory reviewers can be configured. When a merge request is created, the list is automatically synchronized to the merge request.

Example of a mandatory reviewer list:

The Reviewers Required is 2. If the list of mandatory reviewers is empty, the 2 approvers in the list of New Reviewers give pass and the gate is passed.
The Reviewers Required is 2. If the list of mandatory reviewers is not empty, the gate can be approved only after at least one reviewer in the list give pass.