Merge — vad är det, typer av sammanslagning och funktionsmekanism

Vad är Merge?

Merge (sammanslagning) — är en grundläggande operation i Git som slår samman ändringar från en gren (source) till en annan (target). Som ett resultat av sammanslagningen får mål-grenen alla commits från käll-grenen som ännu inte fanns i den. Beroende på situationen kan Git utföra merge på tre olika sätt.

Huvudvärdet med merge är bevarandet av historik: merge-committen registrerar faktumet av sammanslagning av grenar, lagrar information om när och vilka grenar som slogs samman. Detta underlättar revision av ändringar, sökning efter regressioner och förståelse av utvecklingskronologi. I stora projekt är merge-commit standardsättet för kodintegration.

Enligt data från GitLab Flow används merge-commits i 73 % av team som arbetar med Git. Alternativa tillvägagångssätt (rebase, squash) föredras av team som är inriktade på linjär historik. Valet av strategi beror på teamets storlek, frisläppningsfrekvens och de överenskommelser som antagits i projektet.

När uppstår Merge

Merge krävs när en utvecklare har slutfört arbetet med en funktion och vill integrera den i develop eller main. Ett typiskt scenario: utvecklaren skapade en funktionsgren från develop, arbetade i några dagar, och under den tiden dök nya commits upp i develop från andra deltagare. Före sammanslagning måste ändringarna kombineras — och för detta används merge.

Utan merge är det omöjligt att samarbeta på samma kod i Git. Varje gång två utvecklare samtidigt gör ändringar i samma kodbas, divergerar deras grenar. Merge — är det enda sättet att föra samman dessa ändringar igen utan dataförlust.

Typer av sammanslagning i Git

Git stöder tre typer av merge, var och en avsedd för sitt eget scenario. Valet av sammanslagningstyp påverkar commit-historiken, bekvämligheten med återställning och loggens läsbarhet.

Fast-forward merge

Fast-forward inträffar när mål-grenen inte har haft några nya commits sedan skapandet av käll-grenen. I detta fall flyttar Git helt enkelt mål-grenens pekare framåt till den senaste committen i käll-grenen. Historiken förblir linjär, utan merge-commit.

# Fast-forward merge: develop har inte ändrats sedan feature skapades
git checkout develop
git merge feature/new-login

# Resultat: develop-pekaren flyttade till slutet av feature
# Ingen merge-commit skapades

Fast-forward är bekvämt för kortlivade grenar, där utvecklaren arbetade ensam. Men detta tillvägagångssätt har en nackdel: informationen om att grenen existerade går förlorad — alla commits ser ut som om de gjorts direkt i develop.

Three-way merge

Three-way merge utförs när båda grenarna har nya commits efter divergenspunkten. Git skapar en separat merge-commit med två föräldrar, som registrerar faktumet av sammanslagning av grenar. Detta tillvägagångssätt rekommenderas för funktionsgrenar i teamutveckling.

# Tvingad three-way merge med flaggan --no-ff
git checkout develop
git merge --no-ff feature/new-login

# Merge-commit skapades med standardmeddelande
# Kan ange eget meddelande via -m
git merge --no-ff feature/new-login -m "Merge feature/new-login into develop"

Flaggan --no-ff garanterar skapandet av en merge-commit, även om fast-forward är möjlig. Detta är bästa praxis för att bevara information om förgrening i projektet.

Squash merge

Squash merge komprimerar alla commits från käll-grenen till en och tillämpar den på mål-grenen. Funktionshistoriken går förlorad — en commit med alla ändringar kommer in i grenen. Detta är bekvämt när detaljerade commits i funktionsgrenen inte tillför värde till den övergripande historiken.

# Squash merge: alla commits i feature komprimerades till en
git checkout develop
git merge --squash feature/experimental
git commit -m "feat: experimental login flow (squashed)"

Squash är lämpligt för utkast, experimentella grenar och situationer där det är viktigt att hålla historiken ren. Nackdel — kopplingen till de ursprungliga commits går förlorad, vilket försvårar återställning av enskilda ändringar.

Ours och Theirs strategier

Ours och Theirs — två speciella merge-strategier i Git. Ours ignorerar helt ändringar från käll-grenen och behåller bara det som finns i mål-grenen. Theirs accepterar tvärtom käll-grenens version vid varje konflikt. Dessa strategier är användbara vid sammanslagning av stora mängder kod, när man i förväg vet vilken version som ska vinna.

Hur fungerar Merge

Mekanismen för merge i Git är baserad på jämförelse av tre punkter: den gemensamma förfadern (merge base), tillståndet för käll-grenen och tillståndet för mål-grenen. Git hittar merge base — den senaste committen som är gemensam för båda grenarna — och beräknar vilka ändringar som har skett i varje gren efter divergens.

• Steg 1 — Git bestämmer merge base: den senaste committen som finns i båda grenarna
• Steg 2 — Git bygger två diffar: från merge base till source och från merge base till target
• Steg 3 — Git försöker tillämpa båda ändringsuppsättningarna på merge base
• Steg 4 — Om ändringarna inte kolliderar — avslutas merge automatiskt
• Steg 5 — Om det finns en konflikt — stannar Git och begär lösning

Git använder trevägs-algoritmen för sammanslagning, som inte bara tar hänsyn till de två jämförda versionerna av filen, utan även deras gemensamma förfader. Tack vare detta kan Git automatiskt lösa situationer där ändringar i en gren inte påverkar de ändrade delarna av den andra — även om båda filerna har modifierats.

Merge-algoritmens funktion med exempel

Betrakta scenariot: två utvecklare arbetar på olika filer i samma funktionsgren. Den första ändrade LoginActivity.kt, den andra — ProfileFragment.kt. När de slår samman sina ändringar ser Git att ändringarna berör olika filer och utför merge automatiskt, utan mänsklig inblandning.

Om båda utvecklarna ändrade LoginActivity.kt, men i olika metoder — kommer Git också att hantera det automatiskt, genom att slå samman ändringarna rad för rad. En konflikt uppstår bara om båda ändrade samma rader eller om den ena tog bort kod som den andra ändrade.

Lösa konflikter vid Merge

Merge-konflikt uppstår när Git inte automatiskt kan slå samman ändringar, eftersom båda grenarna har ändrat samma rader på olika sätt. I detta fall markerar Git konfliktområdena i filerna och väntar på manuell lösning från utvecklaren.

Konfliktområden markeras med speciella markörer: <<<<<<< HEAD visar kod från mål-grenen, ======= — avskiljaren, >>>>>>> source-branch — kod från käll-grenen. Utvecklaren måste manuellt välja vilken variant som ska behållas eller kombinera dem.

# 1. Starta merge och se konflikten
git merge feature/new-login
# Utdata: CONFLICT (content): Merge conflict in LoginActivity.kt

# 2. Visa listan över filer med konflikter
git status
# both modified: src/ui/login/LoginActivity.kt

# 3. Lös konflikten: redigera filen, ta bort markörer
# 4. Lägg till den lösta filen och slutför merge
git add src/ui/login/LoginActivity.kt
git merge --continue
# eller: git commit (utan --continue)

För att lösa konflikter finns det verktyg: git mergetool öppnar en visuell merger (Meld, Beyond Compare, VS Code). Många utvecklare föredrar att lösa konflikter i IDE — IntelliJ IDEA och Android Studio tillhandahåller ett inbyggt verktyg med trepanelsjämförelse som avsevärt förenklar denna process.

Tips för att lösa konflikter: förstå alltid vad varje sida av konflikten gör, ta inte bort andras kod utan att förstå dess logik, och om konflikten är för komplex — involvera författaren till båda grenarna i den gemensamma lösningen.

Merge vs Rebase: när ska man välja vad

Valet mellan Merge och Rebase — ett av de vanligaste arkitektoniska besluten i Git. Båda tillvägagångssätten kombinerar ändringar, men gör det på olika sätt: merge bevarar förgreningshistoriken, rebase skriver om historiken och gör den linjär.

• Merge — bevarar sammanhanget: det syns när och från vilken gren sammanslagningen gjordes. Bättre för publika grenar (develop, main) och teamarbete
• Rebase — skapar en ren linjär historik utan onödiga merge-commits. Bättre för personliga funktionsgrenar före inskick för granskning
• Regel: rebasa aldrig publika grenar som används av andra utvecklare

Många team använder en hybridansats: rebase för att uppdatera funktionsgrenen till develops aktuella tillstånd (git rebase develop), sedan merge med flaggan --no-ff för att registrera sammanslagningen. Detta ger en ren historik inom funktionen och informativa sammanslagningspunkter på develop-nivå.