Sammanfogning (merge) — vad är det, hur fungerar merge och strategier för sammanfogning

Vad är merge i Git

Merge — detta är kommandot git merge som kombinerar ändringar från den angivna grenen till den aktuella grenen. Git hittar den gemensamma anfadern (gemensam bascommit), beräknar diffen för varje gren i förhållande till anfadern och skapar en merge-commit som innehåller den kombinerade uppsättningen av ändringar. Resultat — målgrenen kompletteras med alla ändringar från den sammanfogade grenen.

Syntax: när du befinner dig i målgrenen (t.ex. main), utför git merge feature. Git skapar automatiskt en merge-commit om det inte finns några konflikter. I standardmeddelandet för merge-commit står: “Merge branch ’feature’ into main”. Meddelandet kan ändras via flaggan -m eller redigeras i den öppna editorn.

Merge är en icke-förstörande operation. Till skillnad från rebase rör merge inte befintliga commits: de förblir med samma hash, författare och datum. Detta gör merge till det enda säkra sättet att slå samman grenar som flera utvecklare arbetar med samtidigt. Om något går fel kan merge avbrytas med kommandot git merge --abort.

# Växla till målgren
git checkout main

# Slå samman feature-gren
git merge feature

# Resultat — merge-commit med två föräldrar
git log --oneline --graph

# Slå samman med anpassat meddelande
git merge feature -m "feat: integrate authentication module"

Typer av merge: regular, squash, fast-forward

Git stödjer tre sammanfogningslägen som väljs beroende på önskat resultat. Regular merge (standard) skapar en merge-commit. Squash merge slår ihop alla commits från feature-grenen till en. Fast-forward — flyttar grenpekaren framåt utan att skapa en commit, om möjligt. Valet av läge beror på teamets workflow och historikregler.

Regular merge (--no-ff) — skapar en merge-åtagande även om sammanfogningen kan utföras som fast-forward. Rekommenderas för main-grenen: merge-commit markerar explicit ögonblicket för funktionsintegrering och möjliggör enkel återställning av alla ändringar från feature-grenen med en enda revert av merge-commit. GitHub använder detta läge som standard när PR slås samman via Merge-knappen.

Squash merge (--squash) — samlar alla commits från feature-grenen till en enda commit i målgrenen. Användbart när feature-grenens grova historik inte ska komma in i main. Nackdel: förbindelsen till originalcommits går förlorad — man kan inte se hur funktionen utvecklades steg för steg. GitHub använder detta läge vid val av “Squash and merge” i PR.

Fast-forward (--ff) — om målgrenen inte har några nya commits efter featurens förgrening, flyttar Git helt enkelt pekaren framåt, utan att skapa en merge-commit. Historiken förblir linjär. Flaggan --no-ff tvingar fram skapandet av en merge-commit, --ff-only avslutas med fel om fast-forward inte är möjligt.

# Tvinga merge-commit (rekommenderas för main)
git merge --no-ff feature

# Squash merge — alla commits till en
git merge --squash feature
git commit -m "feat: add authentication"

# Endast fast-forward om möjligt
git merge --ff-only feature

# Avbryt konfliktfylld merge
git merge --abort

Git sammanfogningsstrategier

Sammanfogningsstrategier bestämmer algoritmen som Git använder för att kombinera ändringar. Varje strategi är lämplig för olika scenarier. Git väljer automatiskt lämplig strategi, men utvecklaren kan ange den explicit via flaggan --strategy. Att förstå strategier hjälper till att förutsäga Gits beteende vid komplexa sammanfogningar.

Recursive — standardstrategi för sammanfogning av två grenar. Git hittar den gemensamma anfadern, beräknar ändringarna i varje gren och kombinerar dem. Om den gemensamma anfadern hittas hanterar recursive korrekt omdöpning av filer och tillägg av nya. Vid konflikter kan recursive använda ytterligare alternativ: ours (automatiskt välja vår version) och theirs (välja deras version).

Octopus — för samtidig sammanfogning av fler än två grenar: git merge feature1 feature2 feature3. Octopus stödjer inte konfliktlösning — alla konflikter måste lösas innan kommandot anropas. Används sällan, främst för att kombinera flera oberoende grenar som garanterat inte kolliderar (t.ex. olika moduler).

Ours — en speciell strategi som helt ignorerar ändringar från den sammanfogade grenen och bevarar det aktuella innehållet i målgrenen. Merge-commit skapas, men innehållet förblir oförändrat. Användbart när man behöver registrera sammanfogningen i historiken men praktiskt taget avvisa alla ändringar från den andra grenen.

Lösa merge-konflikter

Merge-konflikt uppstår när samma rader i en fil har ändrats på olika sätt i båda grenarna. Git kan inte automatiskt avgöra vilken version som är korrekt och pausar merge. Konflikt kan också uppstå vid omdöpning av en fil i en gren och dess ändring i en annan, eller vid samtidig borttagning och ändring av samma fil.

Lösningsprocess: Git markerar konfliktfiler med markörer. I filen visas avsnitt med <<<<<<< HEAD (vår version), ======= (avskiljare) och >>>>>>> feature (deras version). Utvecklaren redigerar manuellt konfliktavsnittet, väljer nödvändiga rader från båda versionerna, tar bort markörerna, sparar filen och lägger till den i indexet via git add.

För visuell konfliktlösning stödjer Git mergetool — ett externt jämförelseverkyg. Populära mergetool-verktyg: Meld, KDiff3, Beyond Compare, VS Code (inbyggd konfliktredigerare). Mergetool visar tre paneler: vår version, deras version och resultatet. Utvecklaren väljer visuellt kodblock för inkludering i slutfilen.

# Påbörja merge och upptäck konflikt
git merge feature
# KONFLIKT (innehåll): Merge-konflikt i src/main.swift

# Kontrollera konfliktfiler
git status

# Öppna visuell mergetool
git mergetool

# Efter lösning — lägg till och committa
git add src/main.swift
git commit

# Avbryt merge
git merge --abort

När välja merge istället för rebase

Merge är att föredra framför rebase i flera viktiga situationer. Första: när man arbetar med offentliga grenar som är tillgängliga för andra utvecklare. Merge skriver inte över historiken och kollegor kan synkronisera sig säkert. Rebase i en offentlig gren skapar en divergent historik och konflikter för alla som redan har tagit emot gamla commits.

Andra situationen: när en feature-gren slutförs. De flesta team föredrar merge (med flaggan --no-ff) till main för att registrera ögonblicket för funktionsintegrering. Detta förenklar navigering genom historiken och möjliggör enkel återställning av hela funktionen med en enda git revert av merge-commit. GitHub Flow erbjuder som standard tre merge-alternativ: enkel merge, squash merge och rebase merge.

Tredje situationen: när man arbetar med en pull request som har granskats. GitHub och GitLab erbjuder merge-knapp med olika alternativ. Merge (Create a merge commit) — fullständig historik med merge-commit. Squash and merge — ren historik utan utvecklingsdetaljer. Rebase and merge — linjär historik utan merge-commit, men med om skrivning av commits. Valet beror på teamets regler.

• Offentliga grenar (main, develop) — endast merge, aldrig rebase.
• Slutföra PR — merge med --no-ff för att registrera integrationsögonblicket.
• Grenar med andras commits — merge skriver inte över andras arbete.
• Före release — merge är säkrare eftersom det innebär mindre risk.
• Delad gren — om flera utvecklare arbetar på grenen är merge obligatoriskt.

Bästa praxis för sammanfogning av grenar

Första regeln: var alltid på den aktuella versionen av målgrenen före merge. Utför git checkout main && git pull innan du slår samman funktionen. Detta minimerar konflikter och garanterar att merge-commit kommer att innehålla alla aktuella ändringar. Om målgrenen har gått långt framåt, utför först git merge main inuti feature-grenen för att lösa konflikter i dess sammanhang.

Andra regeln: testa koden efter merge. Merge kan ändra beteendet, även om det inte fanns några konflikter. CI/CD-pipelinen bör köra tester på merge-commit innan den skickas till produktion. Vissa team använder merge gates — obligatoriska kontroller som blockerar merge tills de har godkänts.

Tredje regeln: dokumentera merge-commits. Standardmeddelandet “Merge branch ’feature’ into main” är föga användbart. Det rekommenderas att lägga till en beskrivning av vad som slogs samman: “Merge authentication module: login, registration, password recovery”. Detta förenklar analys av historiken och sökning efter regressioner. I stora projekt genereras merge-commits automatiskt från PR-namnet.

• Aktualitet — före merge, se till att målgrenen är uppdaterad (git pull).
• Testning — CI/CD bör köra tester på den resulterande merge-commit.
• Beskrivande meddelanden — ange i merge-commit vilken funktion som slogs samman.
• Frekvens — slå samman feature-grenar så tidigt och ofta som möjligt (maximalt en vecka).
• Ångra — git revert av merge-commit återställer hela funktionen fullständigt.