This topic describes the branch settings for a code repository.
Background information
Branch settings consist of two parts:
Default branch settings
The default branch is the base branch for cloning, creating branches, creating merge requests, and browsing code. It can also be protected from accidental deletion. A code repository manager can change the default branch to match the team's development practices.
Protected branch settings
A protected branch restricts deletions and force pushes. A code repository manager can set up rules to protect important branches, prevent accidental deletions and force pushes, and ensure the security of key branches and the traceability of their commits.
Access branch settings
As a code repository manager, navigate to your code repository and click on the top menu bar.
Create a protected branch rule
Follow these steps to create a protected branch rule:
Step 1: Select a branch
You can specify a branch in one of two ways:
Method 1: Enter the full name of a specific branch.
Method 2: Use a wildcard pattern (only
?and*are supported). If the pattern matches multiple branches, all matched branches are displayed.If a protected branch matches multiple rules, which rule takes effect?
Precedence: If a branch in the code repository matches multiple protected branch rules, the rule that targets a specific branch name has the highest priority. If a branch matches multiple wildcard rules, the one created first takes precedence.
For example, consider a code repository with the branches
master-1,master-2, andmaster-prod-1. The protection rules are created in the following order:master-*,master-1, andmaster-prod-*. The following table shows how the rules are applied.Branch name
Matching rules
Effective rule
master-1
master-*, master-1
master-1
master-2
master-*
master-*
master-prod-1
master-*, master-prod-*
master-*
Step 2: Configure push rules
Specify which roles and members are allowed to push directly to this protected branch.
Allowed roles: By default, the manager and developer roles are allowed to push. To block a role from pushing, deselect it. If you select
None, no one can push to the branch.Allowed members: You can grant push access to specific members from the code repository. The selected members must have write permissions for the code repository.
Step 3: Configure merge rules
Specify which roles and members are allowed to merge a merge request.
Allowed roles: By default, the manager and developer roles are allowed to merge. To block a role from merging, deselect it.
Allowed members: You can grant merge permissions to specific members from the code repository. The selected members must have write permissions for the code repository.
Permissions for roles and individual members are combined. For example, if you allow only the manager role to push but also specifically allow a developer named User A, then both managers and User A can push to the protected branch, even though User A is not a manager.
Step 4: Configure an approval rule
Configure manual approval rules
You can set the following conditions for a code review:
Allow creator to approve: Yes / No.
Require all code review comments to be resolved before merging.
Two approval modes are available:
General mode:
Minimum number of approvers required: 1.
Roles allowed to approve: manager + developer.
Default reviewers: this section is hidden if no reviewers are specified. You can add up to 20 reviewers.
CodeOwner mode:
For more information about CodeOwner, see CodeOwner Mechanism.
Configure automated check rules
Code scanning
Merge requests cannot be gated by this check unless a code scanning task is enabled. For configuration details, see Use the code detection service.
After you enable the code scanning task, you can require it as a merge gate.
Pipeline check
For a protected branch, you can integrate with a Flow pipeline to add merge gates for merge requests.
If the code repository is not associated with a pipeline, go to Alibaba Cloud DevOps Flow to create or associate a pipeline. See How to associate a Flow pipeline.
ImportantTo automatically trigger the pipeline check on each code commit, select the code commit trigger event when you create the pipeline. Otherwise, you must manually trigger the pipeline to get the check result, as its result is required for the merge request to pass.
After you associate a pipeline, you can select it here to use as a merge gate.
The selected pipeline becomes a required check for any merge request that targets this protected branch. The pipeline must pass before the request can be merged.
ImportantEnsure the pipeline designated as a merge gate has successfully run at least once.