Skip to content

Navigation Menu

Sign in
Sign up

Enabling branch protection and pull request gating #525

plz12345 started this conversation in General
Discussion options

Proposing a couple of minor, but important protections, now that there are more cooks in the kitchen with permission to merge.

  1. Set main as a protected branch
  2. Enable pull request reviews/approvals prior to merge
  3. No self-approvals, you can't submit a PR and approve your own submission

Org owners can technically bypass this, but it's bad form to do so without a good reason.

This prevents an "oops" situation, since we're currently only working on one branch. In the future, this can and should shift to a dev -> main pipeline for commits and versions, but above is fine, sane, and easy.

We discussed this in another thread somewhere, but I've lost track, and it's probably in one of the catch-alls that should be broken out into smaller targeted discussions.

Any concerns?

You must be logged in to vote

Replies: 3 comments 6 replies

Comment options

Yes, agree 100%
When do we want to move to a DEV branch?

@fxd0h, can I ask that you please make these changes to main branch protection when you are ready.

BTW: I made a tiny change to the README this morning... though didn't do a PR self-approval.
I'm in the NEVER EVER commit your own PR to main camp.

Feature Description Free Org (public repos) Team/Enterprise
Prevent force pushes Block rewriting commit history ✅ Yes ✅ Yes
Prevent branch deletion Stop the branch being deleted ✅ Yes ✅ Yes
Require pull request before merging No direct pushes; changes via PR only ✅ Yes ✅ Yes
Require status checks CI/CD checks must pass before merge ✅ Yes ✅ Yes
Require signed commits Commits must be GPG/SSH signed ✅ Yes ✅ Yes
Require linear history Enforce squash/rebase merges only ✅ Yes ✅ Yes
Require multiple PR reviewers Mandate more than one approving review ❌ Paid only ✅ Yes
Code owners approval Require sign-off from CODEOWNERS file ❌ Paid only ✅ Yes
Restrict who can push Limit pushers to specific users/teams ❌ Paid only ✅ Yes
Required reviewers Specify exact required reviewers on PRs ❌ Paid only ✅ Yes
Private repo protections Any protection on private repos ❌ Paid only ✅ Yes
Org-wide rulesets Apply rules across all repos in an org ❌ Enterprise only ✅ Enterprise
You must be logged in to vote
3 replies
Comment options

plz12345 Aug 11, 2026
Collaborator Author

I can make the changes, just wanted agreement before I did.

Comment options

Agreed - thanks

Comment options

Agreed, table stakes for main branch management.

Comment options

Done. main now requires a PR with one approval and green fast-tests; force pushes and deletions are blocked, and owners can still technically bypass, per the bad-form clause. The bots stay advisory on purpose: a rate-limited or NEUTRAL bot check should not be able to freeze the queue.

You must be logged in to vote
0 replies
Comment options

Following up in this thread since it holds the original agreement. Two drifts since then.

The context we agreed to require was fast-tests. That workflow got renamed along the way, and the rules moved from classic protection into rulesets, so today the only check actually gating main is lint. Tests still run green on every PR, they just don't block anything anymore.

Meanwhile #685 landed the release process, and its release-note check is designed to block: the PR template ships the block empty so that filling it (or writing none) is a conscious call. While the check stays advisory, an unfilled block can merge anyway and someone has to catch it by hand at release time.

I'd like the required checks to be lint, tests and release-note, with the bots staying advisory as we set them. If no objections I can apply it to the ruleset like last time.

You must be logged in to vote
3 replies
Comment options

OK, by me...

Comment options

fxd0h Sep 1, 2026
Maintainer

Applied. The main-protection ruleset now requires lint, tests and release-note; bots stay advisory.

Comment options

plz12345 Sep 2, 2026
Collaborator Author

Yeah, it's needed. More friction, especially when someone is "in the zone" with PR reviews.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

AltStyle によって変換されたページ (->オリジナル) /