Du kjørte git pull, og i stedet for de forventede endringene ble du møtt av en rød linje i terminalen: fatal: refusing to merge unrelated histories. Prosjektet ble ikke oppdatert, commits ble ikke hentet, og du sitter og lurer på om du ødela repositoryet.

Nei, du ødela det ikke. Git nekter rett og slett å blande to uavhengige historikker, og dette er tilsiktet oppførsel, ikke en feil. Om fem minutter vil du ikke bare forstå hvorfor denne feilen oppstår, men også lære å fikse den i enhver situasjon: ved første push, etter å ha mistet .git, og når du slår sammen separate prosjekter.

💡 Rask oversikt:

• Når Git nekter å slå sammen urelaterte grener og hvorfor dette er riktig
• Flagget --allow-unrelated-histories, en universell løsning for pull, merge og første push
• Steg-for-steg-scenarier: kloning uten historikk, nytt repository, rebase og force-push
• Hva du gjør hvis flagget ikke hjelper, og hvordan du unngår denne feilen i fremtiden

Hva feilen betyr og hvorfor Git kaster den

Git sporer historikk gjennom en kjede av commits. Hver commit refererer til sin forelder, og bygger en graf som Git bruker for å forstå hva som kom hvorfra. Når du gjør git merge, ser Git etter en felles stamfar mellom to grener og beregner differansen fra den.

Men noen ganger finnes det rett og slett ingen felles stamfar. To commit-grafer krysser ikke hverandre, som to separate prosjekter som aldri visste om hverandre. I en slik situasjon nekter Git å slå sammen historikker blindt og kaster:

1
fatal: refusing to merge unrelated histories

Dette er ikke en feil i vanlig forstand. Det er beskyttelse: Git forteller deg: «Jeg forstår ikke hvordan disse to historikkene henger sammen, så jeg vil ikke gjette.» Løsningen finnes, og den er innebygd i Git fra og med versjon 2.9.0 (utgitt i juni 2016).

To typiske scenarier som fører til feilen

Første scenario, ødeleggelse eller sletting av .git-mappen. Du klonet et prosjekt, jobbet med koden, men .git-mappen ble slettet (ved et uhell, av antivirus, eller ved kopiering uten skjulte filer). Git mister all lokal historikk og behandler arbeidskatalogen din som et helt nytt prosjekt, uten tilknytning til det eksterne repositoryet ved forsøk på git push eller git pull.

Andre scenario, et nytt repository møter et eksisterende. Du kjørte git init, la til flere commits lokalt, og prøvde deretter å koble til et eksternt repository som allerede har sin egen historikk. Git ser to uavhengige commit-grafer og nekter å blande dem. Dette skjer ofte når du starter et prosjekt fra bunnen av, og deretter bestemmer deg for å laste det opp til GitHub oppå et eksisterende repository, eller når du overfører kode fra ett prosjekt til et annet.

Begge scenariene løses med samme mekanisme, men før du bruker den, bør du forstå nøyaktig hva du ønsker å oppnå: å slå sammen to historikker til én eller å fullstendig erstatte én historikk med en annen.

Løsning: flagget --allow-unrelated-histories

Nøkkelen til å fikse dette er flagget --allow-unrelated-histories. Det forteller eksplisitt Git: «Jeg vet at disse grenene ikke har noen felles stamfar, og jeg ønsker bevisst å slå dem sammen.» Flagget fungerer med begge hovedkommandoene, git pull og git merge.

**For **git pull (det vanligste tilfellet):

1
git pull origin main --allow-unrelated-histories

Bytt ut main med ditt grens navn hvis det er annerledes (master, develop, osv.). Git vil opprette en merge-commit som forbinder de to uavhengige historikkene. En editor vil sannsynligvis åpnes for commit-meldingen, beskriv hvorfor du slår sammen historikkene, lagre og lukk editoren.

**For **git merge (når grener er lokale):

1
git merge feature-branch --allow-unrelated-histories

Etter vellykket merge vil Git be deg om å pushe resultatet. Ikke glem å gjøre dette:

1
git push origin main

Viktig nyanse: --allow-unrelated-histories fjerner ikke merge-konflikter. Hvis begge grener har filer med samme navn, vil Git fortsatt be deg om å løse konflikter manuelt, flagget håndterer kun sammenkobling av historikker, ikke filinnhold.

Steg-for-steg-scenarier for ulike situasjoner

Situasjon 1: første push til et ikke-tomt eksternt repository

Du opprettet et prosjekt lokalt (git init → commits), og på GitHub finnes det allerede et repository med README.md og .gitignore. Direkte git push vil ikke fungere fordi den eksterne grenen inneholder commits du ikke har.

Riktig rekkefølge:

Først hent den eksterne historikken og slå den sammen med din lokale:

1
git pull origin main --allow-unrelated-histories

Løs eventuelle konflikter (vanligvis README.md-konflikter), lag en merge-commit, deretter:

1
git push origin main

Situasjon 2: gjenoppretting etter å ha mistet.git

.git-mappen er slettet, men arbeidskatalogen er intakt. Du kan gjenopprette tilkoblingen til det eksterne repositoryet uten å miste ikke-committede endringer:

1
git init
2
git remote add origin <repository-url>
3
git fetch origin
4
git reset --mixed origin/main

Kommandoen git reset --mixed synkroniserer Git-indeksen med den eksterne grenen, men lar alle arbeidsfilene dine være urørte. Etter dette, legg til endringer og lag en ny commit:

1
git add .
2
git commit -m "Recovery after losing .git"
3
git push origin main

Denne tilnærmingen er å foretrekke fremfor --allow-unrelated-histories fordi den ikke oppretter en kunstig merge-commit og holder historikken ren.

Situasjon 3: rebase med urelaterte historikker

Kommandoen git rebase kan også kaste denne feilen, spesielt når du bruker flagget --preserve-merges (nå erstattet med --rebase-merges). Løsning, legg til --allow-unrelated-histories:

1
git rebase --rebase-merges --allow-unrelated-histories main

Men vær forsiktig: rebase omskriver historikk, og hvis noen andre jobber med denne grenen, vil du skape problemer for dem. For delte grener, foretrekk alltid merge.

Hva du gjør hvis flagget ikke hjelper

Noen ganger fungerer --allow-unrelated-histories uten feil, men resultatet er ikke det du ønsket.

Problem: merge-commit roter til historikken. Hvis du slo sammen to store prosjekter, blir commit-grafen vanskelig å lese. I dette tilfellet, vurder et alternativ, overføring av filer med historikkbevaring via git format-patch og git am:

1
git format-patch --root -o patches/ HEAD
2
git am patches/*.patch

Problem: etter merge kompilerer ikke prosjektet. Sammenslåing av urelaterte historikker kan føre til dupliserte konfigurasjonsfiler, avhengighetskonflikter eller inkompatible pakkeversjoner. Etter --allow-unrelated-histories, sjekk alltid: avhengigheter (npm install / composer install), konfigurasjonsfiler (.env, config/), stier og importer i kode. Bedre å bruke fem minutter på verifisering nå enn å håndtere feilende bygg i CI senere.

Problem: du ombestemte deg. Du kan rulle tilbake en merge av urelaterte historikker på standard måte, git reset --hard HEAD~1 (hvis du ikke har pushet resultatet ennå) eller git revert -m 1 HEAD (hvis du allerede har pushet).

Hvordan unngå feilen i fremtiden

Tre enkle regler som vil spare deg for denne feilen i det daglige arbeidet.

Ikke slett .git uten absolutt nødvendighet. Hvis du trenger å kopiere kode uten historikk, bruk git archive eller kopier filer bevisst uten den skjulte .git-mappen, ikke ved et uhell.

Ikke opprett et nytt repository inne i et eksisterende. Hvis du trenger å trekke ut en del av kodebasen til et separat prosjekt, bruk git subtree split eller git filter-branch (nå anbefales git filter-repo). Disse verktøyene vil bevare historikken til nødvendige filer, og Git vil vite hvor de kom fra.

Før git init i en mappe med kode, sjekk alltid om det allerede finnes et repository der: git status. Hvis Git svarer fatal: not a git repository, kan du initialisere. Hvis den viser status, er du allerede inne i et eksisterende repository og git init er ikke nødvendig her.

For de som nettopp har begynt å jobbe med Git, anbefaler vi vår guide «Git-guide for nybegynnere», den går gjennom SSH-nøkler, opprettelse av repository og hele GitHub-arbeidsflyten steg for steg. Og hvis Git ikke er installert ennå, start med guiden «Hvordan installere Git på Windows».

⁉️🤔 Ofte stilte spørsmål

Hvilke Git-versjoner støtter --allow-unrelated-histories?

Flagget dukket opp i Git 2.9.0 (juni 2016) og er til stede i alle påfølgende versjoner. Hvis din Git-versjon er eldre, oppdater den: kommandoen git --version vil vise gjeldende versjon, og git update-git-for-windows (på Windows) eller systemets pakkebehandler vil oppdatere til den nyeste utgivelsen. Den enkleste måten å sjekke Git-versjonen på er kommandoen git --version i terminalen. Per midten av 2026 er den gjeldende grenen 2.48+. Hvis du er på Windows og Git ble installert for lenge siden, last ned et nytt installasjonsprogram fra git-scm.com, automatisk oppdatering i gamle versjoner fungerte ustabilt.

Kan jeg bruke flagget med git push direkte?

Nei, git push aksepterer ikke --allow-unrelated-histories. Push oppretter ikke en merge, den sender bare eksisterende commits. Feilen «unrelated histories» ved push betyr at din lokale gren og den eksterne har divergert på historikknivå. Løsning: først git pull --allow-unrelated-histories, løs konflikter, og først deretter git push. Formelt fungerer --allow-unrelated-histories med git fetch + git merge og med git pull (som internt gjør fetch + merge). Push forblir en separat operasjon som du utfører etter vellykket merge. Ikke prøv å omgå dette med --force, du vil miste andre personers commits på det eksterne repositoryet.

Hva er best for ren historikk: merge eller rebase?

For å koble sammen urelaterte historikker, definitivt merge. Rebase i denne konteksten skaper flere problemer enn det løser: det prøver å spille av commits fra én gren oppå en annen, men uten en felles stamfar fører dette til konflikter på hver commit. Merge med --allow-unrelated-histories gjør nøyaktig det som trengs, oppretter ett tilkoblingspunkt mellom to grafer, hvoretter historikken er samlet. Unntak: når du bevisst ønsker å omskrive historikk og vet nøyaktig hva du gjør. For eksempel ved overføring av kode fra ett repository til et annet med opprydding av gamle commits. I dette tilfellet kan git rebase --allow-unrelated-histories være meningsfylt, men for daglig arbeid, velg merge.

Jeg mistet .git-mappen, men jeg har ikke-committede endringer. Vil jeg miste dem?

Nei, du vil ikke miste dem. Selve .git-mappen inneholder kun historikk og Git-metadata, men ikke arbeidsfilene dine. Alle endrede, nye og til og med ikke-committede filer vil forbli urørte i arbeidskatalogen. Gjenopprettingsprosedyren er beskrevet i «Situasjon 2» ovenfor, git init → git remote add → git fetch → git reset --mixed. Nøkkelpunkt: bruk nøyaktig --mixed, ikke --hard. Flagget --mixed tilbakestiller indeksen, men bevarer alle endringer i filer. Hvis du er usikker, ta en sikkerhetskopi av hele prosjektmappen før gjenoppretting, dette tar ti sekunder og eliminerer fullstendig risikoen for datatap i enhver ikke-standard situasjon.

Feilen oppstår ved kloning gjennom en IDE. Er dette det samme problemet?

Ja, det samme. Noen IDE-er (for eksempel PHPStorm, Visual Studio, eldre versjoner av IntelliJ) initialiserer et nytt Git-repository når de oppretter et prosjekt fra en mal, og prøver deretter å koble til en ekstern. Dette er nøyaktig det andre scenariet fra begynnelsen av artikkelen. Løsningen er den samme: åpne en terminal i prosjektmappen og utfør git pull origin main --allow-unrelated-histories. Etter manuell merge vil IDE-en plukke opp den nye tilstanden automatisk, bare oppdater prosjektvinduet eller klikk Refresh i Git-panelet.

Bør du frykte feilen «unrelated histories»?

Nei. Dette er en av de tryggeste Git-feilene, den ødelegger ikke data, sletter ikke filer og forhindrer ikke fortsatt arbeid. Flagget --allow-unrelated-histories er ikke en krykke eller workaround, men en dokumentert funksjonalitet spesielt lagt til av Git-utviklerne for tilfeller der du bevisst ønsker å koble sammen to uavhengige historikker.

Når du har mestret denne kommandoen, får du et kraftig verktøy: nå kan du slå sammen prosjekter uansett isolasjonsgrad, overføre kode mellom repositories og gjenopprette arbeid etter å ha mistet .git, og alt dette uten panikk og uten å gjenskape repositoryet fra bunnen av. Hvis Git lærte deg noe i dag, er det at «fatal» i meldingene ikke betyr «fatalt for prosjektet», det betyr «jeg vil ikke gjette, fortell meg eksplisitt hva jeg skal gjøre.»