Du har laget en nettside for en kunde, og nå skal du bygge en ny innlogging. Gjør du det rett i koden som ligger ute, ser kunden alt som er halvferdig, og ingenting stopper en feil fra å nå de som bruker siden. Branches løser det. Du bygger i en egen versjon, og den ekte siden går upåvirket videre til du er klar.
Hva en branch er
En branch er en parallell versjon av prosjektet. Endringer du gjør i én branch, er usynlige i de andre til du slår dem sammen. Hovedbranchen heter som regel main, og regelen er enkel: det som ligger i main, skal alltid virke, fordi det ofte publiseres automatisk.
Mange team har i tillegg en dev-branch der nye ting samles og testes sammen, og en feature-branch for hver funksjon som utvikles. Jobber ett team med innlogging og et annet med nytt design, lever arbeidet i hver sin branch. Først i dev ser man om de to virker sammen, og først da går det videre til main.
Opprett og bytt branches
I GitHub Desktop lager du en ny branch fra menyen Current branch øverst. I terminalen gjør du det med tre kommandoer: git branch viser alle branches med en stjerne ved den du står på, git branch dev lager en ny, og git switch dev flytter deg dit. Trykk Tab mens du skriver navnet, så fullfører terminalen det for deg.
Du vil også møte git checkout. Det er den gamle kommandoen for å bytte branch, og den virker fortsatt, men den kan også forkaste endringer i filer. At samme kommando gjør to så forskjellige ting, er grunnen til at Git fikk switch og restore som tydeligere alternativer.
Tips: Gi branchene navn som sier hva de inneholder, for eksempel «4-lage-footer». Lager du branchen fra et issue på GitHub, får den nummeret til issuet automatisk.
Slå sammen med merge eller pull request
git merge drar en annen branch inn i den du står på. Skal dev inn i main, går du først til main og skriver git merge dev. Det virker, men da er det bare du som har sett koden før den havner i hovedbranchen.
I et team bruker man heller en pull request. Det er en GitHub-funksjon, ikke en Git-funksjon: du pusher branchen, ber om å få den slått sammen, og en kollega leser gjennom endringene før noen trykker merge. Jo flere øyne, jo færre feil i produksjon.
Merge-konflikter og code review
Har to branches endret den samme linjen på hver sin måte, kan ikke Git gjette hvilken versjon som skal vinne. Sammenslåingen stopper, og Git markerer begge versjonene i filen. Du velger, lagrer og committer, og mergen er ferdig. Det er en vanlig del av hverdagen, ikke et tegn på at noe er ødelagt.
I en code review åpner kollegaen pull requesten, går gjennom fanen Files changed fil for fil, og skriver kommentarer på linjene som trenger en forklaring. Er prosjektet koblet til en tavle i GitHub Projects, flyttes oppgaven automatisk til Done når pull requesten blir godkjent og slått sammen.
Fra artikler til nettkurs
Artiklene her er hentet fra kurset Git og GitHub på Utdannet.no. Der oppretter, bytter, gir nytt navn til og sletter du branches, lager en merge-konflikt med vilje og løser den både i terminalen og i GitHub Desktop, og går gjennom et helt løp fra issue til feature-branch, pull request og godkjent code review med to forskjellige brukere.
