8.3 Versjonskontroll og samarbeid

Mange hender, samme kode

Git er det dominerende verktøyet for versjonskontroll i moderne programvareutvikling. Du kjenner allerede grunnleggende commits, men når flere jobber på samme kode samtidig, trenger vi mer. Nøkkelbegrepet er branch (forgreining) – en parallell versjon av kodebasen der du kan jobbe isolert uten å påvirke hovedversjonen (main eller master).

Det finnes vanlige branching-strategier med navnekonvensjoner. Feature branches har én branch per ny funksjon, navngitt som feature/brukerprofil. Bugfix branches retter feil, som bugfix/login-crash. Release branches forbereder en ny versjon, som release/v2.1.0. Og hotfix branches håndterer kritiske feil i produksjon som må fikses umiddelbart, som hotfix/security-patch. Du oppretter og bytter til en ny branch med git checkout -b feature/ny-funksjon.

Fordelen er enorm. Hver utvikler kan jobbe på sin egen funksjon i sin egen branch, uten at halvferdig kode fra én person ødelegger for de andre. Når en funksjon er ferdig og testet, fletter man den inn i hovedversjonen. Slik kan et helt team jobbe parallelt på samme prosjekt, og main forblir alltid en stabil versjon som virker.

Merging og konflikter

Når en branch er ferdig, må endringene merges (flettes) inn i en annen branch. Det finnes to varianter. En fast-forward merge skjer når målbranchen ikke har fått nye commits siden du forgrenet – da flyttes bare peker fram, helt uten problemer. En three-way merge skjer når begge brancher har nye commits; da lager Git en egen merge-commit som kombinerer endringene.

Men noen ganger oppstår en merge-konflikt: samme linje er endret i begge brancher, og Git vet ikke hvilken som er riktig. Si at to utviklere har endret samme config.py ulikt. Når den ene prøver å merge, stopper Git og markerer konflikten i filen med spesielle markører:

<<<<<<< HEAD
DATABASE_URL = "postgresql://localhost/testdb"
=======
DATABASE_URL = "postgresql://localhost/myapp"
>>>>>>> main

Du løser den i fire steg: rediger filen manuelt og velg riktig versjon (eller kombiner dem), fjern konfliktmarkørene <<<<<<<, ======= og >>>>>>>, kjør git add på filen, og git commit. Ofte krever det at de to utviklerne snakker sammen om hva som er rett. Et alternativ til merge er rebase, som flytter dine commits til toppen av en annen branch og gir en renere, lineær historikk – men du må aldri rebase på delte (public) brancher, fordi det omskriver historikk som andre allerede bygger på.

Pull requests og GitHub Flow

Det som virkelig binder teamsamarbeid sammen, er pull requests (PR), også kalt merge requests. En pull request er en formell forespørsel om å flette din branch inn i main. Men den er mer enn det – den er et sted for kodegjennomgang (code review). Når du åpner en PR, kan kollegene dine se nøyaktig hva du har endret, kommentere på enkeltlinjer, foreslå forbedringer og godkjenne før koden slippes inn i hovedversjonen. Dette fanger feil tidlig, sprer kunnskap i teamet, og holder kvaliteten oppe.

Den typiske arbeidsflyten kalles GitHub Flow, og den er enkel. Du lager en branch fra main, gjør endringene dine og committer dem, åpner en pull request, får gjennomgang og eventuell godkjenning, og merger så til main. Etter merging slippes endringene ofte rett til produksjon, fordi main alltid holdes klar til bruk. Denne flyten passer godt for kontinuerlig leveranse, der man slipper små endringer ofte i stedet for sjeldne, store utgivelser.

Læringen er at versjonskontroll handler om mye mer enn å lagre kode. Brancher gir isolasjon, merging samler arbeidet, og pull requests gir et strukturert sted for samarbeid og kvalitetssikring. Sammen lar dette mange utviklere bygge på samme prosjekt uten kaos – og det er nettopp dette som gjør Git til ryggraden i nesten all moderne programvareutvikling.

Oppsummering

Versjonskontroll lar mange hender jobbe på samme kode. Brancher gir isolasjon, med strategier som feature-, bugfix-, release- og hotfix-brancher. Merging samler arbeidet igjen, enten som fast-forward eller three-way merge, og merge-konflikter løses ved å redigere filen, fjerne konfliktmarkørene, og committe – mens rebase aldri skal brukes på delte brancher.

Det limet som binder samarbeidet, er pull requests, som gir et strukturert sted for kodegjennomgang og godkjenning før merging. GitHub Flow beskriver den enkle syklusen fra branch til pull request til main. Sammen gjør dette Git til ryggraden i moderne utvikling. I neste kapittel ser vi på dokumentasjon og vedlikehold.