Du skriver git merge dev for å få den nye funksjonen inn i main, og i stedet for en bekreftelse får du dette: «CONFLICT (content): Merge conflict in index.html. Automatic merge failed; fix conflicts and then commit the result.» Åpner du filen, er den full av piler og likhetstegn. Ingenting er ødelagt. Git har bare funnet en endring den ikke kan avgjøre selv, og venter på at du skal velge.
Hvorfor merge-konflikter oppstår
Når to branches slås sammen, sammenligner Git endringene i hver av dem. Har de rørt forskjellige linjer, eller forskjellige filer, fletter Git dem sammen automatisk. Det skjer i de aller fleste tilfeller, og du merker ingenting.
Konflikten kommer når begge branchene har endret den samme linjen, og på hver sin måte. I kurset er eksemplet en enkel nettside. I main endres linjen «Hei» til «Hei på deg». I dev har noen bestemt at linjen skal bort, og sletter den. Begge endringene er committet og pushet. Når dev skal inn i main, finnes det ingen riktig løsning Git kan regne seg frem til. Skal linjen stå med ny tekst, eller skal den være borte? Det er et valg bare et menneske kan ta.
Slik leser du konfliktmarkørene
Git skriver begge versjonene inn i filen, med tre markører rundt:
- <<<<<<< HEAD markerer starten på din versjon, altså det som står i branchen du står på. Når du merger dev inn i main, er det main.
- ======= skiller de to versjonene.
- >>>>>>> dev markerer slutten på den innkommende versjonen, fra branchen du merger inn.
Mellom HEAD og likhetstegnene står altså «Hei på deg». Mellom likhetstegnene og dev står ingenting, fordi dev slettet linjen. Det er hele konflikten. Resten av filen er flettet sammen som vanlig.
Slik løser du en merge-konflikt i terminalen
- Kjør git status. Filer med konflikt står under «Unmerged paths» og er merket «both modified».
- Åpne filen og finn markørene. Har filen flere konflikter, er hver av dem markert for seg.
- Bestem hva som skal stå. Du kan beholde din versjon, den innkommende, begge, eller skrive en ny linje som kombinerer dem.
- Slett alle tre markørene, og lagre filen.
- Kjør git add . for å fortelle Git at konflikten er løst.
- Kjør git commit -m "Løs merge-konflikt i index.html". Commiten fullfører mergen.
- Kjør git push hvis branchen skal opp på GitHub.
Kjører du git merge dev på nytt etterpå, svarer Git «Already up to date». Det er bekreftelsen på at mergen er ferdig. I git log ser du nå begge de opprinnelige endringene, og commiten som løste konflikten. Med git show og ID-en til den commiten ser du nøyaktig hva du valgte.
Tips: Ombestemmer du deg midt i en merge, kjører du git merge --abort. Da går alt tilbake til slik det var før du skrev git merge, og du kan prøve igjen når du har snakket med den som skrev den andre versjonen.
Løs konflikten i Visual Studio Code eller GitHub Desktop
Du trenger ikke slette markørene for hånd. Visual Studio Code fargelegger konflikten, med din versjon i grønt og den innkommende i blått, og legger fire valg rett over den: Accept Current Change, Accept Incoming Change, Accept Both Changes og Compare Changes. Ett klikk, og markørene er borte.
I GitHub Desktop får du en dialog med filene som har konflikt. Derfra kan du åpne filen i editoren eller avbryte med Abort merge. Når du har løst konflikten og lagret, viser dialogen at det ikke er flere konflikter igjen, og du fullfører med Continue merge.
Merge-konflikter i en pull request
Bruker teamet pull requests, oppdager du ofte konflikten på GitHub i stedet for i terminalen. Pull requesten viser da at branchen har konflikter som må løses før den kan slås sammen. Enkle konflikter kan løses rett i nettleseren med knappen Resolve conflicts, som viser de samme markørene som i filen. Større konflikter er tryggere å løse lokalt: hent main inn i feature-branchen din, løs konflikten der, test at alt virker, og push på nytt. GitHub har en egen guide til å løse merge-konflikter på GitHub.
Slik får du færre og mindre konflikter
Du kommer ikke unna merge-konflikter hvis du jobber med andre. Men du kan gjøre dem små nok til at de tar et halvt minutt i stedet for en ettermiddag.
- Hent ofte. Jo lenger det går mellom hver gang du henter andres endringer, jo flere linjer har dere rukket å endre begge to. Hvordan fetch og pull skiller seg, står i Forskjellen på git fetch og git pull.
- Hold branchene korte. En branch som lever i to dager, gir sjelden store konflikter. En som lever i to måneder, gjør nesten alltid det.
- Si fra når du rydder. Omformatering av en hel fil, eller å flytte kode rundt, rører hundrevis av linjer. Gjør det i en egen commit, og fortell teamet før du gjør det.
- Les før du velger. Den vanligste feilen er ikke selve konflikten, men å trykke Accept Current Change uten å skjønne hva den andre endringen skulle løse. Spør personen som skrev den hvis du er i tvil.
Denne videoen er hentet fra kurset Git og GitHub på Utdannet.no. I det fulle kurset lager du konflikten med vilje i to branches og løser den både i terminalen og i GitHub Desktop, og lærer branches, git merge og pull requests i samme prosjekt. Editoren i kurset er en variant av Visual Studio Code.
