Hvordan fungerer merge i Git?

Question

Accepted Answer

**Merging** kombinerer ændringer fra en branch ind i en anden — typisk ved at bringe en afsluttet feature branch tilbage til hovedbranchen. Git håndterer de fleste merges automatisk, men det er vigtig at forstå merge-typer og **konflikter**. ## Basis merge ```bash git switch main # be on the branch you want to merge INTO git merge feature-x # merge feature-x's changes into main ``` Du skifter til **target** branchen (den der modtager ændringer) og merger **source** branchen ind i den. ## Fast-forward vs merge commit ```text FAST-FORWARD merge → if main hasn't changed since the branch was created, Git just MOVES main's pointer forward to the branch's latest commit (no merge commit, linear) MERGE COMMIT (three-way merge) → if BOTH branches have new commits, Git creates a new "merge commit" combining them (has two parents) → preserves that a merge happened → git merge --no-ff forces a merge commit even when fast-forward is possible ``` Git udfører fast-forward når det er muligt (blot ved at flytte pointeren fremad) eller opretter en **merge commit** (med to forældre) når begge branches er divergeret. ## Merge konflikter ```text A CONFLICT happens when both branches changed the SAME lines differently — Git can't auto-decide which to keep, so it asks YOU to resolve: ``` ```text <<<<<<< HEAD the version from the current branch (main) ======= the version from the branch being merged (feature-x) >>>>>>> feature-x ``` ```bash # resolve: edit the file to the desired result, remove the markers, then: git add # mark the conflict resolved git commit # complete the merge # git merge --abort # or cancel the merge entirely ``` **Konflikter** opstår når begge branches ændrer de samme linjer — Git markerer dem og du vælger manuelt det korrekte resultat, derefter staged og commit du. ## Hvorfor det betyder noget At forstå merging er essentielt, fordi det at kombinere branch-ændringer er en fundamental, konstant del af samarbejdsorienterede Git-workflows, så det at vide hvordan det fungerer (inklusiv konflikter) er nødvendig daglig viden. **Merging** er hvordan færdigt arbejde (typisk feature branches) bliver integreret tilbage i hovedbranchen — den rutinepræget handling at bringe ændringer sammen, der sker kontinuerligt i teamudvikling. At forstå forskellen mellem en **fast-forward merge** (Git blot flytte pointeren fremad når target ikke er divergeret, hvilket holder historikken lineær) og en **merge commit** (en tre-vejs merge, der opretter en ny commit med to forældre når begge branches har nye commits, og der registreres at en merge fandt sted) præciserer hvordan Git integrerer ændringer og hvordan den resulterende historie ser ud. Mest vigtigt er det at forstå **merge konflikter** — som opstår når begge branches ændrer de samme linjer forskelligt, så Git ikke kan beslutte automatisk og spørger dig om at løse det — er afgørende praktisk viden: konflikter er en normal, uundgåelig del af samarbejde, og at vide hvordan man genkender konfliktmarkørerne (`<<<<<<<`, `=======`, `>>>>>>>`), redigerer filen til det korrekte resultat og færdiggør merge'en (stage og commit) er en væsentlig færdighed, der ofte er en kilde til bekymring for dem, der ikke forstår det. Fordi det at integrere branch-ændringer via merging er fundamental og konstant i samarbejdsorienteret udvikling, og fordi det at forstå merge-typer og især at løse konflikter er nødvendigt for at kombinere arbejde korrekt (en rutinepræget, uundgåelig opgave), er det at forstå hvordan merging fungerer — basis merges, fast-forward vs merge commits og konfliktløsning — væsentlig, hyppigt anvendt Git-viden, en kernefærdighed for samarbejde hvor konfliktløsning især er en praktisk nødvendighed, som hver udvikler må håndtere med tillid.