Du har fått en e-post: en kollega har bedt deg om review på en pull request. Du åpner den, ser 14 endrede filer og vet ikke helt hvor du skal begynne, eller hva du skal se etter. Code review i GitHub er enklere enn det ser ut, og verktøyene for å gjøre det grundig ligger rett foran deg.
Hele løpet, fra oppgave til godkjent kode
Code review er ett ledd i en flyt der alt henger sammen. I kurset ser den slik ut, med oppgaven «Lage footer», som er issue nummer 4:
- I issuet klikker du Create a branch under Development i sidepanelet. GitHub lager en branch med nummeret i navnet, for eksempel «4-lage-footer», som er koblet til issuet.
- Hent branchen til maskinen med git fetch origin og git switch 4-lage-footer.
- Skriv koden, og commit med issue-nummeret i meldingen, for eksempel git commit -m "Legg til footer #4".
- Push branchen, og lag en pull request på GitHub. Med feature-branches er det vanlig å slå dem inn i dev, ikke rett i main.
- Velg en reviewer. Du kan ikke velge deg selv, og det er hele poenget.
- Koble pull requesten til prosjektet, slik at tavlen i GitHub Projects følger med.
Fra nå av er det revieweren som har ballen.
Slik finner du det du skal se gjennom
Under fanen Pull requests kan du filtrere på det som angår deg. Review requests viser pull requests der noen har bedt om din vurdering, og Involves me viser alt du er nevnt i. Åpne pull requesten, og les beskrivelsen før du ser på koden. Den skal fortelle hva endringen gjør og hvorfor.
Fanen Conversation viser historikken: commits, kommentarer og statusendringer. Fanen Commits lar deg gå gjennom endringene én commit av gangen, som ofte er lettere å følge enn alt på én gang.
Gå gjennom koden i Files changed
Files changed er der selve gjennomgangen skjer. Hver fil vises med lagte til linjer i grønt og fjernede i rødt.
- Kommenter en linje. Hold musepekeren over linjenummeret og klikk plusstegnet. Skriv spørsmålet ditt der det hører hjemme: «Hvorfor er denne endret?»
- Merk filer som sett. Avkrysningsboksen Viewed ved hver fil kollapser den. Med mange filer holder du oversikten over hva du har lest.
- Få en oppsummering. Har du tilgang til Copilot, kan du be den forklare hva som er endret. Det er en hjelp til å forstå, ikke en erstatning for å lese.
- Sjekk Checks. Har prosjektet automatiske tester med GitHub Actions, viser fanen Checks om de har gått gjennom. Rød test betyr at koden ikke skal inn ennå.
Godkjenn, kommenter eller be om endringer
Når du har lest gjennom, klikker du Review changes og velger ett av tre:
- Comment gir tilbakemelding uten å ta stilling. Nyttig når du bare har spørsmål.
- Approve godkjenner endringene. Pull requesten kan slås sammen.
- Request changes betyr at noe må rettes før den kan godkjennes. Forfatteren retter, pusher på nytt, og du ser over igjen.
Er alt i orden, klikker du Merge pull request og Confirm merge. Feature-branchen dras inn i dev, pull requesten får status Merged, og fordi den var koblet til prosjektet, flytter oppgaven seg til Done på tavlen av seg selv.
Når det er du som får kommentarene
Har revieweren bedt om endringer, retter du dem i den samme branchen, committer og pusher. Pull requesten oppdaterer seg selv, så du trenger ikke lage en ny. Svar på hver kommentar, enten med hva du endret eller hvorfor du lot det være, og klikk Resolve conversation når en tråd er avklart. Til slutt ber du om ny gjennomgang med pilene ved revieweren i sidepanelet, slik at kollegaen får beskjed om at det er klart.
Hva du bør se etter
En god review handler mindre om å finne skrivefeil og mer om å stille spørsmålene forfatteren ikke stilte seg selv.
- Gjør koden det beskrivelsen sier, og løser den oppgaven i issuet?
- Hva skjer hvis brukeren gjør noe uventet, som å la et felt stå tomt?
- Kommer det med filer som ikke skal være der, som en .env-fil eller testkode?
- Vil du forstå koden selv om et halvt år?
Tips: Kommenter koden, ikke personen. «Kan vi flytte dette til en egen funksjon?» blir tatt imot helt annerledes enn «Dette er rotete». Spør heller enn å konkludere, så får du ofte en forklaring du ikke hadde tenkt på.
Vil du at ingen skal kunne slå noe inn i main uten godkjent review, kan eieren av repoet sette opp en regel for branchen under Settings. Da er code review ikke lenger en god vane, men et krav. GitHub beskriver det i dokumentasjonen om pull request-reviews.
Hvordan pull requesten lages fra forfatterens side, står i Slik lager du en pull request i GitHub, og oppgavene og tavlen som løpet starter i, er forklart i Slik planlegger du arbeidet med GitHub Issues og Projects.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset går du gjennom hele løpet med to forskjellige brukere, fra issue og feature-branch til pull request, review og en oppgave som flytter seg til Done av seg selv.
