Branch protection on private repos costs $4/month. That's why AL-2.1 got blocked. Here's why GitHub charges for it, what your three paths forward look like, and a clear recommendation for your situation.
GitHub is owned by Microsoft. It makes most of its money from companies running private repositories for proprietary code. To keep individual hobbyists on the platform, they offer a generous free tier for public projects — including all the branch-protection rules we just covered. But to nudge companies toward paid plans, the same features on private repositories require a paid tier.
That's it. There's no technical reason it can't work on private free repos. It's a price wall between hobbyist usage and business usage. The cheapest tier that unlocks it is GitHub Pro at $4/month per user.
GitHub has a second, newer system called Rulesets. It does the same job as branch protection but with cleaner JSON. AL-2.1 tried both endpoints — same paywall on both. So "branch protection" and "Rulesets" are effectively the same feature for our purposes, gated the same way.
All three of these are legitimate. They differ in cost, in privacy, and in how robust the enforcement is. The right pick depends on how you feel about the trade-offs:
You click upgrade in GitHub's settings UI. Branch protection becomes available immediately. AL-2.1's blocked request re-runs and succeeds. You stay private, your methodology stays yours, and the doorman is on duty.
required_approving_review_count from 0 to 1 with no other changesSwitch the repo from private to public in settings. Branch protection unlocks instantly because it's free for public repos. Everything you've ever committed becomes browsable by anyone with the URL — including your in-progress methodology, your draft skills, and (eventually) Josh's work.
Don't pay; don't go public. Rely entirely on the local pre-commit hooks that AL-2.2 is about to build (Husky + Gitleaks + a .private/ walker). They run on your Mac before any commit lands and refuse to stage anything that looks dangerous — secrets, files marked private, etc.
git commit --no-verifyRun your situation through this table. If you're between scenarios, lean on the row closer to where you're heading, not where you've been.
None of these are one-way doors. You can upgrade to Pro later. You can flip a private repo public (or back). You can install/uninstall local hooks anytime. Pick what fits today; revisit when the situation changes.
Solo today, but Josh joining is on the timeline and AL-2.2 is incoming as the local-hooks layer. The single best path for that trajectory is to upgrade to GitHub Pro now. Five reasons:
1. $4/month isn't a real obstacle. Less than one coffee. Expensable as infrastructure. The cost of one accidentally-destroyed branch is way higher than $48/year.
2. Josh joins soon — pre-pay the gate. The moment a second human can push, required_approving_review_count: 1 stops being optional. If Pro is already active, flipping it on is a one-line change. If not, you scramble.
3. Privacy stays intact. The public alternative leaks your methodology, your in-progress thinking, and Josh's eventual work to the open internet. Premature.
4. Belt + suspenders, not either/or. AL-2.2's local hooks are still the primary defense — they catch problems on your Mac before they touch GitHub. Branch protection is the server-side backstop. Pro gives you both layers, not a choice between them.
5. Fully reversible. Cancel anytime. The branch-protection config remains saved server-side; cancelling Pro deactivates enforcement until you reactivate.
This is your call, not GitHub's and not mine. If "$48/year on a hobby project" sets your teeth on edge, Option c (local-only) is a perfectly defensible answer — you'd just be accepting that the server is unenforced until something changes. If you'd be happy open-sourcing the methodology now, Option b (public) is the simplest path and unlocks a future "see how we work" signal. Both are valid; you're not making a mistake either way.
Whichever option you pick, AL-2.2 is the next major dispatch and it builds the real day-to-day discipline layer. It installs three things on your Mac, on every clone of the repo:
The way to think about it: local hooks catch mistakes at the moment of commit, before they reach GitHub at all. Branch protection catches whatever slips through, at the moment of push. They're complementary defenses, not alternatives.
Hooks = the spell-check that fires while you type. Branch protection = the editor who reviews before publication. Most teams want both. AL-2.2 builds the spell-check; whichever option you pick from above determines whether you also have the editor.
--no-verify..private/ walker. Branch protection is the server-side backstop, not a replacement.