Configuring protected branches
If you're a repository owner, you can customize branch protections in the repository and enforce certain workflows, such as requiring more than one peer review or requiring certain status checks to pass before allowing a deployment request to be deployed.
You can create a branch rule in a repository for a specific branch, all branches, or any branch that matches a naming pattern specified with the fnmatch syntax. Below are a few examples of some common practices.
| pattern | matches |
|---|---|
* | all branches |
staging | matches exactly your staging branch |
*prod* | matches any branch containing "prod" |
qa/* | matches any branch beginning with qa/ |
Available options
Require peer reviews in deployment requests
When enabled, deployment requests to these branches are blocked until a required number of approving reviews is met. If any reviewer requests modifications, the deployment remains blocked until the same reviewer submits an approving review later.
Require that unit tests cover at least 75% of the code
When enabled, deployment requests that contain Apex must fulfill the same code coverage requirements that Salesforce enforces for production orgs. Use this setting to detect low coverage early in the release process.
Require all status checks in deployment requests to succeed
When enabled, deployment requests to these branches are blocked if any external checks have failed or are still in progress. External status checks are reported through the Checks API.
Automatically mark checklists as deployed after approvals
When enabled, checklists that target these branches will be marked as "deployed" automatically after a required number of approving reviews. This is useful when trying to include checklists in bulk releases because the last reviewer might forget to mark the checklist as deployed.
Updated 9 days ago