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

mainfeature branchmerge

Branch på GitHub

Feature-branchen er pushet. Commits eksisterer på remote — klar til pull request.

git push -u origin feature/login

PR-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

Openfeature/login → main+128 −12

## Hvad gør denne PR? Tilføjer login-side med JWT-authentication. ## Relateret Closes #42

CI / build
Squash and mergeMerge pull request

Å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.

PR-beskrivelse
## 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.

Undgå
Update
Gør i stedet
feat(auth): tilføj login med JWT

Titlen skal sige hvad PR'en gør — "Update" siger intet.

Undgå
Fixed stuff, please merge ASAP!!!
Gør i stedet
fix(form): valider e-mail og vis fejlbesked

Professionel tone. Beskriv den konkrete rettelse.

Undgå
(ingen beskrivelse)
Gør i stedet
Beskrivelse med hvad / hvorfor / test / Closes #42

Reviewer og kunde skal forstå ændringen uden at gætte.

Undgå
PR med 40 filer og 3 features
Gør i stedet
É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/login

Trin-for-trin guide

Sådan opretter du en PR, får review og merger ind i main.

0 / 5 fuldført

Tjek at alle commits er pushet, at PR'en ikke er for stor, og at du har testet manuelt. Opdater branch fra main hvis nødvendigt.

Terminal
git push origin feature/dashboard

# Opdater fra main hvis teamet har merged:
git checkout feature/dashboard
git merge 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?