Pull Requests
En pull request er jeres kvalitetsport til main — et sted for review, dialog og fælles ansvar. Her får du både den bløde vinkel og den tekniske proces.
Hvorfor pull requests?
I professionelle teams merges der ikke bare kode direkte til main. PRs sikrer kvalitet, synlighed og læring — også i jeres elevprojekter.
- Kvalitetsport til main — En PR er det sted hvor kode tjekkes inden den rammer main — jeres leverance-klare gren.
- Dialog og læring — Review er ikke kontrol for kontrollens skyld. Det er en samtale hvor teamet deler viden og fanger fejl tidligt.
- Dokumentation af beslutninger — PR-beskrivelse, kommentarer og godkendelser gemmer hvorfor I valgte som I gjorde — guld værd uger senere.
- Synlighed for kunden og underviser — Pull requests viser præcis hvad der er bygget i sprinten. Det er jeres historie før release.
Sådan laver vi gode PRs
Vaner der gør review hurtigt, konstruktivt og professionelt.
-
Små PRs
En PR per feature eller fix. Store PRs med 50 filer er næsten umulige at reviewe ordentligt.
-
Beskriv hvad og hvorfor
Titel + beskrivelse skal forklare ændringen for nogen der ikke har siddet i jeres hoved. Link til issue.
-
Vent på review
Merge ikke din egen PR uden at en holdkammerat har set på den — medmindre I har aftalt andet.
-
Grøn CI før merge
Alle checks skal være grønne. En PR med røde tests merges ikke — fix først, så merge.
PR i Git-grafen
Se hvordan en pull request ser ud i Git — fra push til merge på main.
Klik på trinene og se PR'en fra push til merge på main
Branch på GitHub
Feature-branchen er pushet. Commits eksisterer på remote — klar til pull request.
git push -u origin feature/loginPR-livscyklus
Fra oprettelse til merge — klik gennem trinene og se hvordan en PR typisk udvikler sig.
Klik på trinene og se hvordan en PR udvikler sig fra oprettelse til merge
feat(auth): tilføj login med JWT
## Hvad gør denne PR? Tilføjer login-side med JWT-authentication. ## Relateret Closes #42
Åbn pull request
På GitHub: Pull requests → New pull request. Vælg feature branch som source og main som target. Skriv titel og beskrivelse.
💡 Brug "Closes #12" i beskrivelsen for at linke issue automatisk.
PR-beskrivelse — skabelon
Copy-paste og udfyld. En god beskrivelse sparer reviewer for gætteri.
## Hvad gør denne PR?
Kort beskrivelse af ændringen — hvad kan brugeren/kunden nu gøre?
## Hvorfor?
Kontekst: sprint-opgave, bug, kundeforespørgsel.
## Sådan testes det
1. Gå til /login
2. Indtast test-bruger
3. Verificer redirect til dashboard
## Relateret
Closes #42 Review-tjekliste
Brug som reviewer — eller tjek din egen PR inden du beder om review.
- Koden gør det den skal — har du testet manuelt?
- Navngivning og struktur følger projektets konventioner
- Ingen unødvendige filer (console.log, kommenteret kode, node_modules)
- Commit-beskeder er conventional commits
- PR-beskrivelsen forklarer ændringen uden at man skal gætte
- Ingen merge-konflikter — branch er opdateret fra main
Dårlige vs. gode PRs
Titler, tone og størrelse betyder noget.
Update feat(auth): tilføj login med JWT Titlen skal sige hvad PR'en gør — "Update" siger intet.
Fixed stuff, please merge ASAP!!! fix(form): valider e-mail og vis fejlbesked Professionel tone. Beskriv den konkrete rettelse.
(ingen beskrivelse) Beskrivelse med hvad / hvorfor / test / Closes #42 Reviewer og kunde skal forstå ændringen uden at gætte.
PR med 40 filer og 3 features Én PR per feature — fx kun login-flowet Små PRs reviewes hurtigere og bedre.
Fra push til merge
Pull requests lever på GitHub — men Git-kommandoerne er stadig en del af flowet.
Klik på hvert trin for at se forklaring og kommandoer
Branch på GitHub
PR kræver at din feature branch er pushet til GitHub. Uden push kan du ikke oprette en PR.
git push -u origin feature/loginTrin-for-trin guide
Sådan opretter du en PR, får review og merger ind i main.
Test din viden
Svar på spørgsmålene for at tjekke om du har styr på pull requests.
Hvad er hovedformålet med en pull request?
Hvad sker der når du pusher nye commits til en branch med åben PR?
Hvornår bør du merge en PR?
Hvad gør "Closes #42" i en PR-beskrivelse?
Hvem bør typisk godkende (approve) en PR i et elevteam?