Slik får du mer ut av Git branches i hverdagslig utvikling

Git er standardverktøyet for versjonskontroll i de fleste utviklingsmiljøer, men mange utnytter egentlig bare grunnfunksjonene. Branches blir ofte brukt litt vilkårlig, og resultatet kan bli rotete historikk og unødvendig friksjon i teamet.

I denne artikkelen ser vi på en enkel, praktisk måte å bruke branches i Git som faktisk hjelper deg i det daglige arbeidet: mindre kaos, færre konflikter og klarere flyt fra idé til produksjon.

Hva er en branch egentlig, og hvorfor bry seg?

En branch i Git er i praksis en egen linje i historikken der du kan gjøre endringer uten å forstyrre det som allerede fungerer. Tenk på det som et midlertidig verksted hvor du kan teste, ødelegge og forbedre, uten å røre hovedlinjen.

Poenget er ikke å ha flest mulig branches, men å bruke dem til å isolere arbeid: nye funksjoner, bugfiks, eksperimenter og større refaktoreringer. Når du er ferdig, kan du samle alt tilbake i hovedgrenen med en kontrollert prosess.

En enkel branch-strategi som passer de fleste små team

Store organisasjoner har ofte kompliserte oppsett med mange faste branches. For små team og frilansere blir dette fort mer hinder enn hjelp. En lettvektsmodell er ofte nok:

• main: Alltid distribuerbar kode. Det som faktisk kan sendes til kunder eller prod.
• develop(valgfri): Samlepunkt for endringer som snart skal ut, men ikke er helt klare.
• Korte, tematiske feature- eller bug-branches: En branch per oppgave.

Jobber du alene eller med veldig små prosjekter, kan du ofte droppedevelopog bare jobbe rett fra branches motmain. Hovedprinsippet er at du aldri koder direkte på main, bortsett fra helt enkle prosjekter eller små fikser du bevisst velger å gjøre der.

Navngiving som faktisk hjelper deg

Gode branchnavn gjør det lettere å forstå hva som foregår, både for deg selv og andre om noen måneder. Unngå «test», «ny-branch» og «fix2». Bruk et lite mønster:

• feature/…for ny funksjonalitet, for eksempelfeature/ordre-liste-paginering
• bugfix/…for feilretting, for eksempelbugfix/feil-ved-null-pris
• chore/…for vedlikehold, for eksempelchore/oppdater-dependencies-q2

Har du et issuesystem med ID-er, kan du legge dette først i navnet, for eksempelfeature/123-ordre-liste-paginering. Da blir det enkelt å koble kode til oppgave senere.

En konkret arbeidsflyt fra idé til merge

La oss si du skal legge til paginering på en ordreliste i et webprosjekt. En mulig arbeidsflyt med branches kan se slik ut:

1. Start fra main: git checkout main && git pull
2. Lag en ny branch: git checkout -b feature/ordre-liste-paginering
3. Jobb i små biter: Gjør endringer, kjør tester, og lag hyppige commits med beskrivende meldinger.
4. Oppdater branchen underveis: git fetch og git merge origin/main (eller rebase om teamet foretrekker det) når main har beveget seg.
5. Rydd opp før merge: Sørg for at tester går grønt, og at branchen er oppdatert mot main.
6. Opprett pull request(om du jobber i et kodeverktøy som GitHub, GitLab eller Bitbucket).
7. Merge og slett branchennår endringen er godkjent og landet.

Det viktigste her er at hver branch handler om ett tema, at du holder den relativt kortlivet, og at du ikke lar den avvike for mye fra main uten oppdatering.

Vanlige feil som gir kaos i historikken

Noen branch-relaterte problemer dukker opp igjen og igjen, spesielt i team som ikke har snakket gjennom arbeidsmåten. Her er noen typiske fallgruver og enkle måter å unngå dem på:

• For brede branches: Alt fra UI-justeringer til databaseendringer i én og samme branch. Del heller opp i flere små, tematisk konsistente branches.
• Langlivede branches: En branch som ligger og godgjør seg i ukevis, mens main går videre, gir store konflikter. Prøv å lande endringer oftere, eller del arbeidet opp i mindre leveranser.
• Direkte commits på main: Små «hastefikser» direkte på main over tid skaper usikkerhet. Opprett enbugfix/…-branch, selv om endringen er liten.
• Uavklarte merges: Konflikter som «bare» løses lokalt uten at man skjønner hva som egentlig ble resultatet. Ta deg tid til å lese gjennom endringene og test minst én gang etter konfliktløsning.

Merge eller rebase, hva bør du bruke?

Bådemergeogrebasehandler om å kombinere historikk, men de gjør det på ulik måte. Mange diskusjoner om dette blir unødvendig teoretiske. Et pragmatisk oppsett kan være:

• Lokalt på din egen branch: Bruk git rebase main for å holde historikken din rettlinjet og ryddig, siden det kun påvirker din egen branch.
• Inn til main: Bruk git merge via pull request. Da bevares en tydelig logg over hva som ble slått sammen når.

Det viktigste er at teamet blir enige om når rebase er greit, og at man ikke rebaser branches som andre allerede har tatt i bruk. Da risikerer du forvirring og unødvendig feilsøking.

Slik håndterer du hotfixes uten å stoppe alt annet arbeid

Før eller siden dukker det opp en kritisk feil i produksjon mens du jobber på noe helt annet. Da er det fristende å bare committe direkte på main, men det blir fort uoversiktlig. En enkel prosess kan være:

1. Sjekk ut main og oppdater: git checkout main && git pull.
2. Lag en egen branch: git checkout -b hotfix/kritisk-feil-id.
3. Fiks feilen, kjør nødvendige tester og legg til en tydelig commit-melding.
4. Merge inn til main via pull request eller direkte merge.
5. Om du har en develop-branch: merge hotfix inn der også, slik at den ikke «forsvinner» når du senere merger develop til main.

På den måten kan øvrig arbeid fortsette uforstyrret i sine egne branches, samtidig som kritiske feil blir håndtert raskt og sporbarheten ivaretas.

En liten sjekkliste for sunn branch-bruk

Til slutt, en kort sjekkliste du kan bruke i teamet eller alene:

• Oppretter jeg en ny branch for hvert konkret arbeidstema?
• Er navnet på branchen forståelig for meg selv om 6 måneder?
• Har jeg unngått å la branchen leve for lenge uten å synkronisere med main?
• Har jeg sikret at tester kjører grønt før jeg merger?
• Sletter jeg utdaterte branches etter merge, slik at listen ikke blir uoversiktlig?

Om du innfører disse enkle vanene, vil Git gå fra å være et nødvendig onde til å bli et verktøy som faktisk støtter arbeidsflyten din og gjør samarbeidet mer forutsigbart.