Merge og merge-konflikter
Merge er hvor jeres arbejde møder teamets — og konflikter er en normal del af samarbejdet. Her lærer du strategier, løsning og gode vaner.
Hvad er merge — og hvorfor konflikter?
Merge samler to grene. Når I begge har ændret samme linje, kan Git ikke gætte hvad der er rigtigt — så beder den jer om at beslutte.
- Samler teamets arbejde — Merge er øjeblikket hvor jeres feature bliver en del af main — klar til næste sprint og release.
- Integrering kræver samarbejde — Når to har ændret samme kode, skal I aftale hvad der er rigtigt. Det er normalt — ikke en fejl.
- Konflikter er en samtale — En merge conflict siger: "I har begge rørt dette — lad os beslutte sammen." Det er Git der beskytter jer mod at overskrive hinanden.
- Forebyg med gode vaner — Opdater branch fra main ofte, hold PRs små og kommuniker hvem der arbejder på hvad — så får I færre konflikter.
Sådan merger vi
Konventioner der gør merge forudsigeligt og main stabil.
-
Squash and merge på PRs
Som udgangspunkt bruger I "Squash and merge" på GitHub — én pæn commit på main per feature.
-
Opdater fra main før merge
Før I merger: merge eller rebase main ind i jeres branch og løs konflikter dér — ikke på main.
-
Løs konflikter sammen
Forstår du ikke begge ændringer? Tag en kort snak med den der lavede den anden ændring — blind sletning giver bugs.
-
Test efter merge
Efter konfliktløsning: kør appen og tests. Konfliktmarkører væk betyder ikke automatisk at koden virker.
Merge-strategier
På GitHub kan I vælge hvordan en PR merges ind i main. Her er de tre muligheder.
Klik på en strategi for at se fordele, ulemper og hvornår den bruges
Squash and merge
Squasher alle commits fra PR'en til én enkelt commit på main. PR-titel og beskrivelse bliver typisk commit-beskeden.
Fordele
- Ren main-historik — én commit per feature
- Nem at læse git log
- Perfekt til elev-PRs
Ulemper
- Individuelle commits fra branchen forsvinner på main
- Squashed commit får ny hash
Anbefalet som standard i jeres PR-workflow.
Merge — visuelt
Se hvordan main og feature branch mødes — med og uden konflikt.
Klik på trinene og se merge — med og uden konflikt
Hent main ind
Før merge til main: merge main ind i din branch så den er up-to-date.
git checkout feature/dashboard
git merge mainLøs merge-konflikter
Konfliktmarkører (<<<<<<<, =======, >>>>>>>)
viser hvad der skal besluttes. Gå trin for trin og prøv at vælge løsning.
Gå trin for trin gennem løsning af en merge-konflikt
function getTitle() {
<<<<<<< HEAD
return "Dashboard";
=======
return "Projektoversigt";
>>>>>>> main
}Conflict markers i filen
Git indsætter markører i filen: <<<<<<< (din version), ======= (skillelinje), >>>>>>> (main/anden branch). Alt mellem markørerne skal erstattes af den endelige kode.
Forebyg konflikter
Færre konflikter betyder mindre stress og hurtigere merge.
- Merge main ind i din branch mindst dagligt
- Kommuniker hvem der rører samme filer
- Hold PRs små — færre filer = færre konflikter
- Brug issue board så to ikke tager samme opgave
- Løs konflikter med det samme — de bliver ikke bedre med tiden
Merge-flow
Typisk flow: opdater branch fra main → løs konflikter → merge PR på GitHub → pull main lokalt.
Klik på hvert trin for at se forklaring og kommandoer
git pull / merge main
Opdater din branch med det seneste fra main inden merge til main. Konflikter løses her — ikke på main.
git checkout feature/dashboard
git merge mainTrin-for-trin guide
Fra forebyggelse til løst konflikt og færdig merge.
Test din viden
Svar på spørgsmålene for at tjekke om du har styr på merge og konflikter.
Hvad betyder det når Git rapporterer en merge conflict?
Hvilken merge-strategi anbefales som standard til jeres PRs?
Hvad skal du gøre EFTER du har redigeret en fil med konfliktmarkører?
Hvor bør du løse merge-konflikter?
Hvad markerer linjen ======= i en konfliktfil?