GitHub-mainbranch beschermen: let op de beheerdersomzeiling

Wil je directe pushes en ongeteste merges naar main blokkeren, maak dan een klassieke branch protection rule voor die branch. Vereis een pull request en statuschecks, en schakel Do not allow bypassing the above settings in. De uitleg over beschermde branches vermeldt dat beheerders en rollen met bypassrechten anders standaard buiten de beperkingen vallen. Force-pushes en het verwijderen van een beschermde branch zijn standaard geblokkeerd; laat ook de opties om ze toe te staan uitgeschakeld.

Stem vervolgens de revieweis af op de mensen die werkelijk kunnen beoordelen. Werk je alleen, dan kun je pull requests en CI-checks verplicht stellen zonder een goedkeuring te eisen. In een team kun je een goedkeuring door een ander toevoegen. Beide profielen laten wijzigingen via aparte branches doorgaan, terwijl de gekozen controles gelden voor samenvoegen naar main.

Stel de toepasselijke regel voor main in

Open de repository op GitHub en ga naar Settings → Branches → Branch protection rules → Add classic branch protection rule. Vul bij Branch name pattern exact main in. De instructie voor klassieke branchregels noemt Require a pull request before merging, Require status checks to pass before merging en Do not allow bypassing the above settings als afzonderlijke instellingen. Selecteer de checks die elke pull request naar main moet doorlopen en sla de regel op.

Laat Allow force pushes en Allow deletions uitgeschakeld. Kies ook niet voor Lock branch: die optie maakt de branch alleen-lezen en staat daarmee de normale route voor nieuwe commits in de weg. Controleer in een organisatierepository bovendien of onder de pull-requestinstellingen geen personen, teams of apps zijn aangewezen die verplichte pull requests mogen omzeilen. Zo'n expliciete uitzondering past niet bij het doel om iedere wijziging via dezelfde route te laten lopen.

Bekijk vóór het aanmaken of bewerken welke regels main al raken. Van klassieke branch protection rules kan er maar één tegelijk op een branch van toepassing zijn. Een regel met de exacte naam main krijgt voorrang boven een overlappend patroon; bij regels met dezelfde exacte naam krijgt de oudste voorrang. Pas daarom de regel aan die daadwerkelijk geldt, in plaats van erop te vertrouwen dat GitHub de eisen uit verschillende klassieke regels samenvoegt. Meerdere rulesets kunnen wel tegelijk op dezelfde branch gelden.

Kies een profiel voor solo of team

Solo-repository: zet Require a pull request before merging en minstens één relevante, verplichte CI-check aan, maar laat Require approvals uit. Je wijziging loopt dan via een pull request en kan pas worden samengevoegd wanneer de geselecteerde check voldoet. Een verplichte goedkeuring zou hier een blokkade creëren: volgens GitHubs instructie voor reviews kan de auteur zijn eigen pull request niet goedkeuren. Schakel ook in een persoonlijke repository de beheerdersomzeiling uit, zodat de eigenaar dezelfde wijzigingsroute gebruikt.

Teamrepository: behoud de pull-request- en checkeisen en stel één verplichte goedkeuring in als het team een andere beschikbare beoordelaar heeft. Met Require approval of the most recent reviewable push kun je daarnaast eisen dat iemand anders dan degene die de laatste wijziging pushte, die wijziging goedkeurt. Dat is een gerichte keuze wanneer je nieuwe commits na een review wilt laten bekijken. Dismiss stale pull request approvals when new commits are pushed is strenger: een gewijzigde diff kan eerdere goedkeuringen laten vervallen en vraagt dan een nieuwe review.

Kies de reviewopties op basis van de bezetting van de repository. Een verplichte goedkeuring beschermt alleen als iemand die mag beoordelen ook beschikbaar is; anders blijft de pull request wachten. De solo-instelling en de teaminstelling verschillen daarom bewust op reviews, terwijl voor beide de pull-requestroute, verplichte checks en toepassing op beheerders gelijk blijven.

Voorkom dat een statuscheck de merge onbedoeld blokkeert

Geef verplichte CI-jobs unieke namen over alle workflows heen. Als verschillende workflows dezelfde jobnaam gebruiken, kan GitHub de vereiste statuscheck niet eenduidig bepalen en kan een pull request geblokkeerd blijven. Selecteer bovendien alleen checks die bij gewone pull requests naar main daadwerkelijk verschijnen. Een workflow die door een branch- of padfilter niet draait, kan de bijbehorende verplichte check op Pending laten staan.

Bekijk in de mergebox van een proefpullrequest welke checknaam GitHub verwacht en welke status daarbij hoort. Een geslaagde workflow is niet automatisch hetzelfde als een geslaagde vereiste check: de geselecteerde job is beslissend. GitHub accepteert voor een verplichte check ook de statussen skipped en neutral. Als een bepaalde test altijd moet draaien, moet de gekozen job die test dus werkelijk uitvoeren. Wanneer een GitHub App de check levert, kun je die app als verwachte bron instellen; een gelijknamige status van een andere bron voldoet dan niet.

Require branches to be up to date before merging is een afzonderlijke afweging. Met die instelling moet de pull-requestbranch actueel zijn ten opzichte van main, wat na nieuwe merges extra updates en CI-runs kan vragen. Zonder die instelling kunnen eerder geslaagde checks volstaan terwijl main intussen is gewijzigd. Zet haar aan wanneer gelijktijdige wijzigingen een test tegen de nieuwste main noodzakelijk maken; voor een rustige repository kan de minder strikte instelling de doorlooptijd korter houden.

Verifieer de regel met een proefpullrequest

Maak een tijdelijke branch met een onschuldige wijziging en open een pull request naar main. Controleer of GitHub de geselecteerde check verwacht. Laat in een team iemand anders de vereiste review geven; in het soloprofiel hoort geen goedkeuring nodig te zijn.
Laat de verplichte CI-job op de testbranch bewust falen. Samenvoegen moet geblokkeerd blijven, ook als de teamreview al is goedgekeurd. Herstel de fout, laat dezelfde check opnieuw draaien en controleer of de pull request daarna aan de mergevoorwaarden voldoet.
Bereid als repositorybeheerder een kleine testcommit voor en probeer die rechtstreeks naar main te pushen, zonder force-push. De push hoort te worden geweigerd. Wordt hij toch geaccepteerd, controleer dan welke klassieke regel van toepassing is, of de beheerdersomzeiling is uitgeschakeld en of er expliciete uitzonderingen zijn ingesteld.

Kies voor de beheerdersproef een wijziging die je, als de push onverwacht slaagt, veilig via een nieuwe pull request kunt terugdraaien. Een geweigerde rechtstreekse push laat zien dat de beperking ook voor jouw beheerdersaccount geldt; de mislukte check en de daarna geslaagde merge toetsen de gewone ontwikkelroute. Beheerders kunnen de repositoryregels zelf nog beheren, dus deze proef controleert de ingestelde bescherming tegen pushes, niet hun recht om instellingen later te wijzigen.