Praktisk Git-arbeidsflyt alene: fra kaos-commits til ryddig historikk

Mange som jobber alene med kode starter med en enkel vane: commit alt når noe «virker». Etter noen uker er Git-loggen full av meldinger som «fix», «ny test» og «funker vel?», og det blir vanskelig å forstå hva som egentlig har skjedd.

Med noen få justeringer i arbeidsvanene kan du bruke Git som et reelt verktøy for struktur, trygg eksperimentering og kjapp feilsøking, også når du er eneste utvikler på repoet.

Hvorfor det er verdt å ha en god Git-vane selv når du jobber alene

Det kan føles som overkill å ha «ordentlig prosess» når det bare er du som endrer koden. Men om noen måneder er «du i dag» like fremmed som en kollega, og du er avhengig av det du la igjen i historikken.

En gjennomtenkt arbeidsflyt gir deg tre konkrete gevinster: du kan raskt finne tilbake til fungerende versjoner, du tør å gjøre større endringer fordi det er lett å rulle tilbake, og du slipper å lese all koden på nytt for å huske hvorfor ting ble gjort.

Lag små, men hele commits

Nøkkelen til en god historikk er å tenke «en logisk endring per commit». Det betyr ikke at hver commit må være mikroskopisk, men den bør representere en tydelig avgrenset forbedring: ny funksjon, fikset bug, opprydding i struktur.

En enkel huskeregel er at du skal kunne forklare committen i én klar setning: «Legg til validering på e-postfeltet», «Fjern ubrukt API-kall» eller «Ekstraher felles layout-komponent».

Praktisk måte å dele opp endringer

I stedet for å jobbe lenge og så commite alt, kan du stoppe opp når du har fullført en deloppgave. Bruk gjerne verktøy som «stage hunk» i editoren din, eller kommandoer som lar deg velge linjer, for å splitte opp.

Dersom du merker at du har blandet flere typer endringer i samme commit, kan du heller reworke med interaktiv rebase senere, men det krever litt mer erfaring. Start med å tenke i små etapper når du jobber.

Skriv commit-meldinger du selv forstår om et halvt år

Commit-meldinger har én jobb: hjelpe deg å forstå hva som ble endret og hvorfor. Det viktigste er klarhet og konsistens, ikke perfekt stil.

Velg et enkelt format du kan holde på, for eksempel: én linje i presens som beskriver hva koden gjør etter endringen. Unngå interne forkortelser og vage ord som «endring» eller «justering».

Eksempler på gode og dårlige meldinger

Gode commit-meldinger kan være: «Legg til server-side-validering for innloggingsskjema», «Refaktorer ordreberegning til egen modul» eller «Fiks null-feil når kundeliste er tom».

Mindre nyttige meldinger er typisk: «fix», «oppdatering», «småting» eller «wip». Dersom du må skrive «wip», er det ofte et tegn på at du enten bør jobbe litt til, eller dele opp det du har.

Bruk grener smartere, også alene

Mange som er alene på repoet jobber kun på standardgrenen. Det fungerer, men grener gir deg et trygt rom for å teste ting uten å rote til hovedlinjen.

En enkel strategi er: behold en stabil hovedgren som alltid fungerer, og lag korte funksjonsgrener for alt som tar mer enn et par timer eller kan kreve noe eksperimentering.

En enkel grenestrategi du kan huske

Du kan bruke navn som «feature/», «bugfix/» og «chore/» foran grenenavnet for å minne deg selv på intensjonen. For eksempel: «feature/filtrering-av-ordre», «bugfix/invalid-token» eller «chore/oppdater-avhengigheter».

Når du er fornøyd, sørg for at koden kjører og at det ser fornuftig ut, så kan du slå sammen grenen tilbake til hovedgrenen. Slett grenen etterpå for å unngå at listen vokser seg uoversiktlig.

Gjør det lett å rulle tilbake feil

En av de sterkeste grunnene til å bruke Git litt mer bevisst er gleden av å kunne angre uten panikk. Når du har små, men hele commits, blir det mye enklere å bruke verktøy som «revert» eller å hente ut enkeltfiler fra tidligere versjoner.

Det er lurt å ha noen faste steg når du merker at noe har gått galt: stopp og lagre tilstanden, undersøk historikken, og avgjør om du vil reversere en enkelt commit eller gå tilbake til en tidligere versjon for hele katalogen.

En enkel sjekkliste når noe har gått i stykker

• Har du endringer som ikke er committed, men du vil beholde dem? Lag en ny gren før du eksperimenterer med å rulle tilbake.
• Kan problemet knyttes til én spesifikk commit? Da er det ofte tryggest å lage en ny commit som reverserer den.
• Er alt bare rot? Vurder å hente en kjent god commit og kopiere over de få filene du vet du vil beholde.

Rydd opp historikken før du deler eller tagger versjoner

Selv om du jobber alene i et privat repo, kommer det en dag der du vil dele koden med noen, eller i det minste ha en tydelig markering for «versjon 1» eller lignende. Da er det verdt å bruke noen minutter på å se gjennom de siste committene.

Om du ser mange «wip»-commits eller repetitiv støy, kan du bruke interaktiv rebase til å slå sammen beslektede commits, eller omskrive meldinger som er uklare. Gjør dette før repoet er delt bredt, særlig hvis du endrer historikk på hovedgrenen.

Når bør du bruke tags

Tags er nyttige som faste ankerpunkter i historikken når du vet at en bestemt tilstand er viktig. Det kan være første gang du deployer til produksjon, en demo du viste kunden, eller en intern milepæl du vil kunne komme tilbake til.

Gi tagger enkle, men meningsfulle navn, gjerne med versjonsnummer som passer konteksten din, slik at du raskt skjønner hva som ligger bak uten å lete.

Bygg din egen minimale Git-standard

Du trenger ikke kopiere et stort teams prosess for å ha nytte av Git som verktøy for struktur. Start i det små: litt bedre commit-meldinger, enkle grener for alt som er mer enn en kjapp fix, og en vane med å commite ferdige deloppgaver i stedet for kaos-bunter.

Etter hvert kan du legge til flere vaner, som faste tagger for milepæler, rydding i historikken før du lager versjoner, og kanskje hooks eller skript som kjører tester før du committer. Poenget er at Git skal jobbe for deg, ikke omvendt.