Beskyt main på GitHub: stop utestede ændringer før produktion

Beskyttelsen er en port – ikke en kvalitetsgaranti

GitHub kan kræve en pull request, bestemte automatiske checks og eventuelt en godkendelse, før kode flettes til main. Det forhindrer den normale direkte genvej og samler ændring, diskussion, testresultater og beslutning ét sted. Reglen kan derimod ikke vurdere, om testen dækker den rigtige risiko, eller om en godkender faktisk har forstået ændringen.

Find den branch, der faktisk udgiver appen

Beskyt ikke automatisk en branch, bare fordi den hedder main. Kontrollér repositoryets default branch og hostingens deployment-indstilling. Nogle projekter udgiver fra en anden branch, en bestemt mappe eller et særskilt workflow. Hvis porten sættes det forkerte sted, kan den se streng ud uden at beskytte den vej, der rammer produktion.

• Repository: Hvilken branch er default, og hvor ligger den seneste kendte produktionskode?
• Hosting: Hvilken branch eller workflow udløser faktisk deployment?
• Automatik: Kører build og tests på pull requests – eller kun efter merge?
• Adgang: Hvem kan ændre reglerne, pushe, godkende og udgive?

Vælg regler efter den reelle bemanding

En solo-ejer og et udviklingsteam skal ikke have samme opsætning. Pull request-forløbet er stadig nyttigt for én person, fordi diff og checks bliver et stop før merge. Men GitHub tillader ikke, at forfatteren godkender sin egen pull request, så et krav om ekstern godkendelse kan låse et reelt soloprojekt. Sæt kun krav, som nogen faktisk kan opfylde uden en permanent nødgenvej.

Opsæt en lille, håndhævet port på GitHub

GitHub tilbyder både rulesets og klassiske branch protection rules. De kan arbejde samtidig, og tilgængelige funktioner afhænger af repositoryets synlighed og GitHub-plan. Kontrollér derfor den aktuelle mulighed under repositoryets Settings og GitHubs egen dokumentation.

1. Målret produktionsbranchen. Vælg den branch, der er bekræftet som stabil og deployment-udløsende.
2. Kræv en pull request før merge. Så skal ændringer normalt komme fra en anden branch og vises som diff.
3. Blokér sletning og force push. De muligheder bør kun åbnes, hvis et konkret og kontrolleret behov kræver det.
4. Kræv de checks, I stoler på. Vælg stabile jobnavne for build, tests og andre relevante kontroller.
5. Tilføj review, hvis en anden kan tage ansvaret. Ved teamarbejde kan nye kodecommits gøre en tidligere godkendelse forældet.
6. Begræns bypass. En undtagelse skal være sjælden, synlig og efterfulgt af samme kontrol som en normal ændring.

Et krævet check skal altid kunne afgive et svar

GitHub kræver, at et obligatorisk status check har en accepteret afslutning, før der kan merges. Et workflow, der springes over på grund af sti-, branch- eller commitfiltre, kan derfor efterlade pull requesten i venteposition. Brug unikke, stabile jobnavne og afprøv reglerne med både en lille dokumentationsændring og en rigtig kodeændring.

• Kør på pull_request: Kontrollen skal ske før merge, ikke kun efter ændringen er landet.
• Brug reproducerbar installation: Manifest, lockfile og runtime skal passe til den normale produktionsbuild.
• Vælg risikobaserede checks: Login, betaling, dataændringer og migrationsfiler kan kræve mere end lint og build.
• Hold navne entydige: Samme jobnavn i flere workflows kan gøre det uklart, hvilket resultat reglen venter på.
• Dokumentér fejlfinding: Skriv hvem der må ændre workflow eller regel, hvis et check aldrig starter.

Review ændringen – ikke AI-værktøjets forklaring

En pull request-beskrivelse er kun en påstand om ændringen. Gennemgå selve diffen, de berørte filer og checkresultaterne. Ved en AI-genereret ændring er det særligt vigtigt at lede efter ekstra filer, brede omskrivninger og sikkerhedsregler, som ikke var nødvendige for opgaven.

1. Formål: Kan ændringen beskrives konkret, og passer alle ændrede filer til det formål?
2. Adgang og data: Er login, autorisation, secrets, database- eller lagringsregler ændret?
3. Afhængigheder: Er manifest, lockfile, actions eller runtime ændret – også indirekte?
4. Fejltilstand: Hvad oplever brugeren, hvis API, database eller deployment fejler halvvejs?
5. Bevis: Hvilke tests og manuelle kontroller viser, at den konkrete risiko er håndteret?
6. Tilbagevej: Kan kode rulles tilbage, og er eventuelle dataændringer bagudkompatible?

Brug CODEOWNERS, når ansvar følger bestemte filer

En CODEOWNERS-fil kan få GitHub til automatisk at anmode de ansvarlige om review, når bestemte filer ændres. De navngivne personer eller teams skal have de nødvendige repository-rettigheder, og et obligatorisk code-owner-review kræver en tilsvarende regel. Beskyt også selve ejerskabsfilen, så ansvaret ikke kan fjernes ubemærket i samme ændring.

# Standardejer for hele projektet
* @virksomhedens-github-navn

# Ekstra kontrol af udgivelse og database
/.github/ @virksomhedens-github-navn
/migrations/ @virksomhedens-github-navn

Eksemplet er kun en skabelon. Erstat kontonavnet, og vælg kun mapper, som findes i jeres projekt. For et soloprojekt giver filen primært synligt ejerskab; den skaber ikke en uafhængig godkender.

Typiske fejl

• Reglen rammer den forkerte branch: Produktion udgives fortsat fra en ubeskyttet vej.
• Checks kører kun efter merge: Fejlen opdages først, når den stabile branch allerede er ændret.
• Alle admins må altid bypass: Den hurtige genvej bliver den normale arbejdsgang under tidspres.
• Reviewet er kun et grønt flueben: Ingen læser diff, afhængigheder, regler eller migrationsfiler.
• Gamle godkendelser står ved magt: Store nye kodecommits kommer ind efter det review, der gav grønt lys.
• Et check kan springes over: GitHub venter for evigt på et resultat, som workflowet aldrig sender.
• Main beskyttes, men deployment kan startes frit: En separat manuel udgivelsesvej omgår kontrollen.
• Beskyttelse forveksles med backup: En godkendt fejl eller datamigrering kræver stadig rollback og gendannelse.

Tjekliste før main beskyttes

• ☐ Den branch, der udløser produktion, er identificeret.
• ☐ Default branch og seneste kendte produktionscommit er bekræftet.
• ☐ Ændringer laves på en separat, kortlivet branch.
• ☐ Pull requests viser en afgrænset diff og forklarer formål, risiko og test.
• ☐ Build og relevante tests kører på pull_request.
• ☐ De krævede checks har entydige navne og afgiver resultat for normale ændringer.
• ☐ Direkte push, sletning og force push til produktionsbranchen er håndteret bevidst.
• ☐ Reviewkravet passer til antallet af reelle godkendere.
• ☐ Nye kodecommits efter review kræver en ny vurdering, når risikoen kræver det.
• ☐ Bypass er begrænset og har en dokumenteret nødrutine.
• ☐ CODEOWNERS bruges kun, hvor der findes en reel ansvarlig.
• ☐ En prøve-pull request med fejlende test er bekræftet blokeret.
• ☐ En grøn prøve-pull request kan merges og udgives normalt.
• ☐ Rollback og datahåndtering er stadig dokumenteret uden for branchreglen.

Officielle kilder

GitHubs brugerflade, planadgang og tilgængelige regler kan ændre sig. Kontrollér de aktuelle muligheder for netop jeres repository, før en regel håndhæves på produktionsbranchen.

• GitHub Docs: Om pull requests
• GitHub Docs: Opret en branch protection rule
• GitHub Docs: Regler i rulesets
• GitHub Docs: Status checks
• GitHub Docs: Fejlfinding af krævede status checks
• GitHub Docs: Om pull request-reviews
• GitHub Docs: Om CODEOWNERS

Relaterede guides