For each code repository in use, enforce a policy to only allow merging open branches if they are current with the latest change from their origin repository.
For each code repository in use, require open comments to be resolved before the relevant code change can be merged.
For each repository in use, enforce the branch protection rule of requiring signed commits, and make sure only signed commits are capable of merging.
For each repository in use, require linear history and/or allow only rebase merge and squash merge.
For each repository in use, enforce branch protection rules on administrators, as well.
For each repository in use, allow only trusted and responsible users to push or merge new code.
For each repository in use, block the option to “Force Push” code.
For each repository that is being used, block the option to delete protected branches via branch protection rules.
An organization can protect specific code branches — for example, the “main” branch which often is the version deployed to production — by setting protection rules. These rules secure your code repository from unwanted or unauthorized changes. You may set requirements for any code change to that branch, and thus specify a minimum number of reviewers required to approve a change.
For each code repository in use, enforce an organization-wide policy to dismiss given approvals to code change suggestions if those suggestions were updated.
For each code repository in use, carefully select the individual collaborators or groups whom you trust with the ability to dismiss code change reviews.
For every code repository in use, identify particularly sensitive parts of code and configurations and set trusted users to be their code owners.
For each code repository in use, review existing Git branches and remove those which have not been active for a prescribed period of time.
Configure each code repository to require all status checks to pass before permitting a merge of new code.