Jo, nå skal du høre: Når man oppretter en pull request (PR) i et repo i GitHub, er det lurt å ha en god beskrivelse. Beskrivelsen kan være til god hjelp for den som skal gjøre kodegjennomgangen og vurdere om endringen skal godkjennes eller om det trengs noen justeringer.
Hvis man setter opp en mal for pull request-beskrivelsen i repoet, får man automatisk opp et forslag til tekst i pull requesten. I malen kan man ha informasjon og påminnelser til den som oppretter pull requesten om hva slags informasjon som er lurt å ha med, og man kan også inkludere påminnelser om hva som er lurt å ha gjort før man oppretter pull requesten eller hva prosessen skal være etter at pull requesten er opprettet.
Her er det bare fantasien (og Markdown-spesifikasjonen) som setter grenser! (For malen lages nemlig i Markdown-format.)
GitHub har god dokumentasjon for å opprette en pull request-mal,
men kort fortalt er alt du trenger å gjøre dette: Lagre mal-teksten i en fil som heter pull_request_template.md i repoet ditt.
Den kan ligge i rot-katalogen i repoet eller en underkatalog, for eksempel i en katalog som heter .github
for de som liker å ha GitHub-oppsett i en egen katalog.
Det finnes mange gode eksempler der ute, for eksempel denne fra NAV og denne fra Digipost.
Under er et hjemmesnekret eksempel på innhold man kan ha i malen (engelsk versjon finner du her),
som baserer seg på at endringen er gjort vha parprogrammering
slik at selve kodegjennomgangen i prinsippet allerede er gjort mens koden ble skrevet.
I tillegg er de forklarende tekstene "kommentert ut" ved bruk av <!-- (start kommentar) og --> (kommentar slutt),
slik at de som lager PRen bare legger til sin egen tekst etter kommentarene.
<!--Yes! Klart for en siste sjekk før merging.
Legg til info som kommentarene indikerer og så kan dere opprette PR-en.-->
## ❓ Hva og hvorfor?
<!--Beskriv endringen;
- hvorfor endringen blir gjort
- hvordan det fungerte før
- hvordan det kommer til å fungere nå
- hvorfor det ble løst på akkurat denne måten
Dere trenger ikke beskrive **hvordan** endringen er implementert, det ser vi i koden.-->
## ❗️ Verdt å merke seg
<!--Er det noe spesielt som bør nevnes, for eksempel:
- Løsninger som ble vurdert men valgt bort
- Er dette en "breaking change"?
- Må denne endringen gjøres sammen med en endring i andre repoer?-->
## 🧪 Testing og verifisering
<!--Hvordan har dere sjekket at endringen gjør det den skal, uten å knekke eksisterende funksjonalitet?
Hvordan kan vi verifisere at ting fungerer etter at endringen er merget inn?-->
## ✅ Sjekkliste
<!--Kryss av ved å endre fra [ ] til [x].-->
- [ ] Vi har oppdatert relevant dokumentasjon (også generert dokumentasjon)
- [ ] Vi har kjørt kodeformattering og linting
- [ ] Vi har skrevet tester <!--hvis ikke, forklar hvorfor-->
## #️⃣ Saksnummer og lenke
<!--Ta med saksnummer og lenke slik at det er enkelt å finne informasjon om oppgaven.-->
<!-- Og så er dere ferdige. Godt jobba! -->
Slik ser filen ut når den rendres som Markdown (og ikke er puttet inni en text-kodeblokk som den er over), da er ikke kommentarene synlige:
- Vi har oppdatert relevant dokumentasjon (også generert dokumentasjon)
- Vi har kjørt kodeformattering og linting
- Vi har skrevet tester