Git merge conflicts uten panikk: konkret arbeidsflyt for å rydde opp trygt

Før eller siden treffer alle en Git merge conflict midt i en travel dag. Kanskje du bare skulle dra inn siste endringer fra main, og plutselig står terminalen stille med røde meldinger og filer fulle av rare symboler.

Det føles fort som et stopp i hele arbeidsflyten, men merge conflicts er i bunn og grunn bare Git som ber deg ta et bevisst valg. Med en enkel oppskrift og noen faste vaner blir det rutine i stedet for krise.

Hva er en merge conflict, egentlig?

En merge conflict oppstår når Git ikke klarer å kombinere to endringer automatisk. Typisk har du og noen andre endret samme linjer i samme fil, eller én har slettet en fil som en annen har oppdatert.

I stedet for å gjette, ber Git deg manuelt velge hvilke endringer som skal bli med videre. Konflikter er derfor et tegn på at Git er forsiktig, ikke at noe er ødelagt.

Les konfliktmeldingen før du gjør noe som helst

Når en konflikt oppstår etter enmergeellerrebase, forteller Git deg vanligvis ganske tydelig hva som skjedde. Start med å lese output i terminalen i stedet for å prøve nye kommandoer på måfå.

Følg så opp med:

• git statusfor å se hvilke filer som har konflikter
• noter om det er bare én fil, eller mange ulike deler av kodebasen

Dette gir deg et raskt oversiktsbilde og hindrer deg i å overse en konflikt som senere dukker opp i produksjon.

Slik ser konfliktmarkørene ut i filene

Når du åpner en fil med konflikt vil du se spesielle markører som skiller versjonene. De ser omtrent slik ut:

<<<<<<< HEAD
din versjon
=======
innkommende versjon
>>>>>>> feature-branch

Alt mellom<<<<<<< HEADog=======er endringen i din branch. Alt mellom=======og>>>>>>>er endringen fra den andre branchen.

Målet er å redigere dette til én sammenhengende, gyldig versjon av koden. Til slutt skal alle konfliktmarkører være fjernet.

En trygg standardprosedyre steg for steg

Når du lander i en konflikt, kan du bruke denne faste oppskriften som utgangspunkt:

1. Kjørgit statusfor å se hvilke filer som er berørt.
2. Start med den viktigste filen, åpne den i editoren din.
3. Les hva begge sider prøver å oppnå, ikke bare hvilken kode som står der.
4. Kombiner endringene eller velg én versjon, og fjern konfliktmarkørene.
5. Lagre filen, og kjør relevante tester eller byggkommandoer.
6. Marker filen som løst medgit add <fil>.
7. Når alle filer er løst:git commit(for merge) eller fortsett rebase medgit rebase –continue.

Hold deg til denne rekkefølgen til det sitter i fingrene. Det gjør konflikter langt mindre skumle.

Bruk verktøy som hjelper øynene dine

De fleste editorer og IDE-er har innebygd støtte for å vise merge conflicts på en mer lesbar måte. Du får gjerne knapper som “Keep current”, “Accept incoming” eller “Accept both” og visuelle diff-paneler.

I terminalen kan du brukegit difffor å se hva som egentlig skiller versjonene, også etter at du har begynt å rydde. Det gir bedre kontroll enn å bare stirre på rå tekst med konfliktmarkører.

Tre vanlige konfliktsituasjoner og hva du kan gjøre

1. Begge har oppdatert samme funksjon

Her vil du sjelden bare velge én versjon. Les begge endringer og lag en kombinert variant som tar hensyn til begge behov. Skriv gjerne en kort kommentar i koden hvis logikken blir mer kompleks enn før.

Etterpå er det ekstra viktig å kjøre tester og eventuelt manuelt verifisere den delen av løsningen, siden du i praksis har skrevet ny kode.

2. En har slettet filen, en annen har endret den

Git vil spørre om filen skal eksistere eller ikke. Her er det lurt å se på historikken med for eksempelgit log <fil>for å forstå hvorfor den ble slettet.

Hvis slettingen var bevisst opprydding, bør som regel filen fortsatt være slettet, og de nye endringene flyttes til et mer passende sted før du konkluderer.

3. Lange konflikter som spres over flere filer

Store konflikter tyder ofte på at branchene har levd for lenge hver for seg eller at det har vært mye omstrukturering samtidig. I slike tilfeller kan det lønne seg å ta pauser mellom filene.

Løs for eksempel én modul av gangen, kjør tester, og vurder om du burde samarbeide med den som har gjort de andre endringene for å unngå misforståelser.

Gode vaner som reduserer antall konflikter

Du slipper ikke helt unna merge conflicts, men du kan redusere hvor ofte og hvor store de er. Noen enkle grep hjelper mye:

• Trekk inn endringer jevnlig i stedet for én stor oppdatering etter flere dager.
• Del opp arbeidet i mindre enheter som endrer færre filer om gangen.
• Koordiner større omstrukturering i teamet, så ikke alle flytter på de samme modulene samtidig.

Det er også lurt å være litt forsiktig med å blande refaktorering og funksjonelle endringer i samme endringssett. Store kosmetiske endringer gjør det vanskeligere å se hva som egentlig er viktig i konflikten.

Hva om det går galt? Trygge måter å angre på

Noen ganger blir det bare rot, og det er fristende å prøve seg fram. Da er det godt å vite at du kan avbryte:

• git merge –abortfor å stoppe en pågående merge og gå tilbake
• git rebase –abortfor å avbryte en rebase

Disse kommandoene gir deg en ren start igjen, så du kan prøve på nytt med en mer strukturert tilnærming, eller hente hjelp fra en kollega uten å ha blandet inn for mange halvgjorte forsøk.

Gjør merge conflicts til en del av vanlig arbeidsflyt

Konflikter er ikke et tegn på at du “gjør Git feil”, men et naturlig resultat av samarbeid i kodebaser som beveger seg raskt. Nøkkelen er å ha en kjent prosess og holde hodet kaldt når de dukker opp.

Med en tydelig arbeidsflyt, litt hjelp fra verktøyene rundt deg og noen enkle vaner i teamet, går du fra å frykte merge conflicts til å se dem som en vanlig del av utviklingsarbeidet.