Slå samman grenar — vad det är, sätt att slå samman och lösa konflikter

Vad är merge i Git

Merge i Git — är operationen att kombinera två eller flera utvecklingshistorier till en. När en utvecklare slår samman en gren, hittar Git automatiskt den gemensamma förfadern (base commit) och skapar en ny merge-commit som innehåller ändringar från båda grenarna. Three-way merge — standardalgoritmen som jämför tre tillstånd: den gemensamma förfadern, första grenen och andra grenen.

Merge-processen börjar med kommandot git merge. Git bestämmer grenarnas divergenspunkt och tillämpar sekventiellt ändringarna från källgrenen till målgrenen. Om ändringarna inte är i konflikt utför Git fast-forward eller skapar en merge-commit beroende på inställningarna. Fast-forward — scenariot där målgrenen helt enkelt flyttas till källgrenens commits.

# Växla till målgrenen och slå samman
git checkout main
git merge feature/payment-module

# Slå samman med explicit no-fast-forward
git merge --no-ff feature/payment-module

# Avbryt sammanslagning om konflikterna är för komplexa
git merge --abort

Flaggan --no-ff (no fast-forward) tvingar fram skapandet av en merge-commit även när fast-forward är möjlig. Detta bevarar informationen om att ändringarna gjordes i en separat gren. Många team föredrar just detta tillvägagångssätt för att bevara förgreningen av historien i explicit form.

Sätt att slå samman grenar

I Git finns tre huvudstrategier för sammanslagning av grenar, var och en lämplig för ett specifikt scenario. Valet av strategi beror på teamets kultur och kraven på renhet i projektets historik.

Standard merge skapar en merge-commit med två föräldrar. Den fullständiga historiken bevaras, men förgreningsgrafen blir mer komplex. Squash merge kombinerar alla commits från feature-grenen till en och tillämpar den på målgrenen — historiken blir linjär och ren, men information om mellanliggande steg går förlorad.

Rebase, även om det inte är en fullvärdig merge, uppnår samma resultat — ändringar från en gren överförs till en annan. Skillnaden är att historien skrivs om: commits från feature-grenen återskapas ovanpå den sista commiten i målgrenen. Detta ger en perfekt linjär historik, men kräver force push vid sändning.

Hur man löser konflikter vid merge

Konflikt vid merge uppstår när samma rader i en fil har ändrats i två grenar. Git kan inte automatiskt avgöra vilken version som ska behållas och kräver utvecklarens ingripande. Konflikter visas i filer som speciella markörer: <<<<<<<, =======, >>>>>>>.

Processen för att lösa en konflikt omfattar flera steg. Först öppnar utvecklaren den konfliktande filen och väljer manuellt de nödvändiga ändringarna. Det är viktigt att inte bara välja en av versionerna, utan att förstå logiken i båda ändringarna och fatta ett korrekt beslut. Efter redigering av filen tas konfliktmarkörerna bort och ändringarna läggs till i staging area via git add.

# Visa lista över konfliktande filer
git status

# Starta mergetool (t.ex. VS Code, IntelliJ)
git mergetool

# Efter att ha löst alla konflikter
git add .
git merge --continue

# Eller avbryt sammanslagningen helt
git merge --abort

Användning av visuella merge-verktyg påskyndar avsevärt lösningen av konflikter. VS Code, IntelliJ IDEA och GitKraken tillhandahåller gränssnitt med tre paneler: aktuell gren, inkommande gren och resultat. Verktyget git mergetool öppnar automatiskt den konfigurerade editorn för varje konfliktande fil.

Det bästa sättet att undvika komplexa konflikter är regelbunden synkronisering av feature-grenen med huvudgrenen. Om utvecklaren slår samman main med sin gren en gång om dagen blir konflikterna små och lätta att lösa. Ansamling av ändringar under en vecka garanterar komplexa konflikter med hög risk för fel.

När man ska använda rebase istället för merge

Rebase och merge — två sätt att kombinera ändringar, och valet mellan dem orsakar ofta debatter i team. Rebase flyttar commits från en gren till en annan och skriver om historien. Merge skapar en ny merge-commit och bevarar förgreningshistorien. Varje tillvägagångssätt har sina fördelar och begränsningar.

Rebase är lämpligt när en utvecklare arbetar i sin lokala feature-gren och vill få en ren linjär historik innan skapandet av en Pull Request. Efter rebase ordnas alla commits sekventiellt utan onödiga merge-commits. Rebase kräver dock force push och är inte tillämpligt på grenar där flera personer arbetar samtidigt.

• Rebase — för personliga feature-grenar där ren historik behövs
• Merge — för gemensamma grenar och registrering av sammanslagningsögonblicket
• Squash — när feature-grenen innehåller många små arbetscommits

Guldregeln i Git: använd inte rebase på commits som redan har skickats till det delade repositoriet. Detta garanterar att historien i den gemensamma grenen förblir oförändrad och andra utvecklare inte stöter på dubbletter eller förlorade commits. För integration av feature-grenen i huvudgrenen, använd merge via Pull Request.

Bästa praxis för sammanslagning av grenar

Rätt merge-process — grunden för stabil utveckling. I modernt teamarbete utförs merge inte via konsolen utan via Pull Request på GitHub eller Merge Request i GitLab. En PR genomgår code review, automatiska CI-kontroller och först därefter slås den samman i huvudgrenen.

Första praxis — slå endast samman efter att alla kontroller har godkänts. CI-pipelinen måste bygga projektet, köra tester och kontrollera kodkvaliteten. Om ens en kontroll inte har godkänts blockeras merge. Moderna plattformar (GitHub, GitLab) har inbyggt skydd: branch protection rules blockerar automatiskt merge vid CI-fel.

Andra praxis — slå aldrig samman trasig kod. Före merge måste utvecklaren försäkra sig om att hans ändringar inte bryter bygget och inte regresserar befintlig funktionalitet. För detta finns automatiska tester och code review.

Tredje praxis — rensa feature-grenar efter merge. En gren som redan har slagits samman måste tas bort. Detta förhindrar förvirring och skräp i repositoriet. GitHub föreslår automatiskt borttagning av grenen efter merge av en PR, och repositoriets inställningar kan konfigureras för automatisk borttagning.