Du körde git pull, och istället för de förväntade ändringarna mötte terminalen dig med en röd rad: fatal: refusing to merge unrelated histories. Projektet uppdaterades inte, commits drogs inte ner, och du sitter där och undrar om du har förstört repositoryt.

Nej, du har inte förstört det. Git vägrar helt enkelt att blanda två oberoende historiker, och detta är ett avsiktligt beteende, inte en bugg. Om fem minuter kommer du inte bara att förstå varför felet uppstår, utan också lära dig att åtgärda det i alla situationer: vid första push, efter att ha tappat bort .git och när du slår samman separata projekt.

💡 Snabb översikt:

• När Git vägrar slå samman orelaterade grenar och varför detta är korrekt
• Flaggan --allow-unrelated-histories, en universallösning för pull, merge och första push
• Steg-för-steg-scenarier: kloning utan historik, nytt repository, rebase och force-push
• Vad du ska göra om flaggan inte hjälper, och hur du undviker felet i framtiden

Vad felet betyder och varför Git kastar det

Git spårar historik genom en kedja av commits. Varje commit refererar till sin förälder och bygger en graf som Git använder för att förstå vad som kom varifrån. När du gör git merge letar Git efter en gemensam förfader mellan två grenar och beräknar skillnaden utifrån den.

Men ibland finns det helt enkelt ingen gemensam förfader. Två commit-grafer korsar inte varandra, som två separata projekt som aldrig känt till varandra. I en sådan situation vägrar Git att blint slå samman historiker och kastar:

1
fatal: refusing to merge unrelated histories

Detta är inte ett fel i vanlig mening. Det är ett skydd: Git säger till dig, "Jag förstår inte hur dessa två historiker hänger ihop, så jag kommer inte att gissa." Lösningen finns, och den är inbyggd i Git från och med version 2.9.0 (släppt i juni 2016).

Två typiska scenarier som leder till felet

Första scenariot, **korruption eller radering av **.git -mappen. Du klonade ett projekt, arbetade med koden, men .git-mappen raderades (av misstag, av antivirus eller vid kopiering utan dolda filer). Git förlorar all lokal historik och när du försöker git push eller git pull behandlas din arbetskatalog som ett helt nytt projekt, orelaterat till fjärrrepositoryt.

Andra scenariot, ett nytt repository möter ett befintligt. Du gjorde git init, lade till flera commits lokalt och försökte sedan ansluta ett fjärrrepository som redan har sin egen historik. Git ser två oberoende commit-grafer och vägrar blanda dem. Detta händer ofta när du startar ett projekt från grunden och sedan bestämmer dig för att ladda upp det till GitHub ovanpå ett befintligt repository, eller när du överför kod från ett projekt till ett annat.

Båda scenarierna löses med samma mekanism, men innan du tillämpar den bör du förstå exakt vad du vill uppnå: slå samman två historiker till en eller helt ersätta en historik med en annan.

Lösning: flaggan --allow-unrelated-histories

Nyckeln till att åtgärda detta är flaggan --allow-unrelated-histories. Den säger uttryckligen till Git: "Jag vet att dessa grenar inte har någon gemensam förfader, och jag vill medvetet slå samman dem." Flaggan fungerar med båda huvudkommandona, git pull och git merge.

**För **git pull (det vanligaste fallet):

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

Ersätt main med ditt grennamn om det skiljer sig (master, develop etc.). Git kommer att skapa en merge-commit som kopplar ihop de två oberoende historikerna. En editor kommer troligen att öppnas för commit-meddelandet, beskriv varför du slår samman historikerna, spara och stäng editorn.

**För **git merge (när grenar är lokala):

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

Efter lyckad merge kommer Git att be dig pusha resultatet. Glöm inte att göra detta:

1
git push origin main

Viktig nyans: --allow-unrelated-histories tar inte bort merge-konflikter. Om båda grenarna har filer med samma namn kommer Git fortfarande att be dig lösa konflikter manuellt, flaggan hanterar bara sammankoppling av historiker, inte filinnehåll.

Steg-för-steg-scenarier för olika situationer

Situation 1: första push till ett icke-tomt fjärrrepository

Du skapade ett projekt lokalt (git init → commits), och på GitHub finns redan ett repository med README.md och .gitignore. Direkt git push fungerar inte eftersom fjärrgrenen innehåller commits som du inte har.

Korrekt sekvens:

Dra först ner fjärrhistoriken och slå samman den med din lokala:

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

Lös konflikter om några finns (vanligtvis README.md-konflikter), gör en merge-commit, sedan:

1
git push origin main

Situation 2: återställning efter att ha förlorat.git

Mappen .git är raderad, men arbetskatalogen är intakt. Du kan återställa anslutningen till fjärrrepositoryt utan att förlora osparade ändringar:

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

Kommandot git reset --mixed synkroniserar Git-indexet med fjärrgrenen, men behåller alla dina arbetsfiler orörda. Efter detta, lägg till ändringar och gör en ny commit:

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

Denna metod är att föredra framför --allow-unrelated-histories eftersom den inte skapar en artificiell merge-commit och håller historiken ren.

Situation 3: rebase med orelaterade historiker

Kommandot git rebase kan också kasta detta fel, särskilt när du använder flaggan --preserve-merges (nu ersatt med --rebase-merges). Lösning, lägg till --allow-unrelated-histories:

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

Men var försiktig: rebase skriver om historik, och om någon annan arbetar med denna gren kommer du att skapa problem för dem. För delade grenar, föredra alltid merge.

Vad du ska göra om flaggan inte hjälper

Ibland fungerar --allow-unrelated-histories utan fel, men resultatet är inte vad du ville ha.

Problem: merge-commit skräpar ner historiken. Om du slog samman två stora projekt blir commit-grafen svårläst. Överväg i så fall ett alternativ, att överföra filer med historikbevarande via git format-patch och git am:

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

Problem: efter merge kompilerar inte projektet. Att slå samman orelaterade historiker kan leda till duplicerade konfigurationsfiler, beroendekonflikter eller inkompatibla paketversioner. Efter --allow-unrelated-histories, kontrollera alltid: beroenden (npm install / composer install), konfigurationsfiler (.env, config/), sökvägar och importer i koden. Bättre att lägga fem minuter på verifiering nu än att hantera fallerande byggen i CI senare.

Problem: du ångrade dig. Du kan rulla tillbaka en merge av orelaterade historiker på standardvägen, git reset --hard HEAD~1 (om du inte har pushat resultatet ännu) eller git revert -m 1 HEAD (om du redan har pushat).

Hur du undviker felet i framtiden

Tre enkla regler som besparar dig detta fel i det dagliga arbetet.

Radera inte .git utan absolut nödvändighet. Om du behöver kopiera kod utan historik, använd git archive eller kopiera filer exklusive den dolda .git-mappen medvetet, inte av misstag.

Skapa inte ett nytt repository inuti ett befintligt. Om du behöver extrahera en del av kodbasen till ett separat projekt, använd git subtree split eller git filter-branch (nu rekommenderas git filter-repo). Dessa verktyg bevarar historiken för nödvändiga filer, och Git kommer att veta var de kom ifrån.

Innan git init i en mapp med kod, kontrollera alltid om det redan finns ett repository där: git status. Om Git svarar fatal: not a git repository kan du initiera. Om det visar status är du redan inuti ett befintligt repository och git init behövs inte här.

För de som precis börjar arbeta med Git rekommenderar vi vår guide "Git-guide för nybörjare", den går igenom SSH-nycklar, att skapa repository och hela GitHub-arbetsflödet steg för steg. Och om Git inte är installerat ännu, börja med guiden "Hur man installerar Git på Windows".

⁉️🤔 Vanliga frågor

Vilka Git-versioner stöder --allow-unrelated-histories?

Flaggan dök upp i Git 2.9.0 (juni 2016) och finns i alla efterföljande versioner. Om din Git-version är äldre, uppdatera den: kommandot git --version visar den aktuella versionen, och git update-git-for-windows (på Windows) eller din systempakethanterare uppdaterar till den aktuella releasen. Det enklaste sättet att kontrollera Git-versionen är kommandot git --version i terminalen. Från och med mitten av 2026 är den aktuella grenen 2.48+. Om du är på Windows och Git installerades för länge sedan, ladda ner en färsk installationsfil från git-scm.com, automatisk uppdatering i gamla versioner fungerade ostabilt.

Kan jag använda flaggan med git push direkt?

Nej, git push accepterar inte --allow-unrelated-histories. Push skapar inte en merge, den skickar bara befintliga commits. Felet "unrelated histories" vid push betyder att din lokala gren och fjärrgrenen har divergerat på historiknivå. Lösning: först git pull --allow-unrelated-histories, lös konflikter, och först därefter git push. Formellt fungerar --allow-unrelated-histories med git fetch + git merge och med git pull (som internt gör fetch + merge). Push förblir en separat operation som du utför efter lyckad merge. Försök inte kringgå detta med --force, du kommer att förlora andra personers commits på fjärrrepositoryt.

Vad är bättre för ren historik: merge eller rebase?

För att koppla ihop orelaterade historiker, definitivt merge. Rebase i detta sammanhang skapar fler problem än det löser: det försöker spela upp commits från en gren ovanpå en annan, men utan en gemensam förfader leder detta till konflikter vid varje commit. Merge med --allow-unrelated-histories gör exakt vad som behövs, skapar en anslutningspunkt mellan två grafer, varefter historiken är enhetlig. Undantag: när du avsiktligt vill skriva om historiken och vet exakt vad du gör. Till exempel när du överför kod från ett repository till ett annat med rensning från gamla commits. I detta fall kan git rebase --allow-unrelated-histories vara meningsfullt, men för dagligt arbete, välj merge.

Jag har förlorat .git-mappen, men jag har osparade ändringar. Kommer jag att förlora dem?

Nej, du kommer inte att förlora dem. Själva .git-mappen innehåller endast historik och Git-metadata, men inte dina arbetsfiler. Alla modifierade, nya och till och med icke-committade filer kommer att förbli orörda i arbetskatalogen. Återställningsproceduren beskrivs i "Situation 2" ovan, git init → git remote add → git fetch → git reset --mixed. Nyckelpunkt: använd exakt --mixed, inte --hard. Flaggan --mixed återställer indexet men bevarar alla ändringar i filer. Om du är osäker, gör en säkerhetskopia av hela projektmappen före återställning, detta tar tio sekunder och eliminerar helt risken för dataförlust i varje icke-standard situation.

Felet uppstår vid kloning genom en IDE. Är detta samma problem?

Ja, samma. Vissa IDE:er (till exempel PHPStorm, Visual Studio, äldre versioner av IntelliJ) initierar ett nytt Git-repository när de skapar ett projekt från en mall och försöker sedan ansluta en fjärr. Detta är exakt det andra scenariot från början av artikeln. Lösningen är densamma: öppna en terminal i projektmappen och kör git pull origin main --allow-unrelated-histories. Efter manuell merge kommer IDE:n att plocka upp det nya tillståndet automatiskt, uppdatera bara projektfönstret eller klicka på Refresh i Git-panelen.

Ska du vara rädd för felet "unrelated histories"?

Nej. Detta är ett av de säkraste Git-felen, det korrumperar inte data, raderar inte filer och hindrar inte fortsatt arbete. Flaggan --allow-unrelated-histories är inte en krycka eller workaround, utan en dokumenterad funktion som specifikt lagts till av Git-utvecklarna för fall när du medvetet vill koppla ihop två oberoende historiker.

När du har bemästrat detta kommando får du ett kraftfullt verktyg: nu kan du slå samman projekt oavsett grad av isolering, överföra kod mellan repositoryn och återställa arbete efter att ha förlorat .git, och allt detta utan panik och utan att återskapa repositoryt från grunden. Om Git lärde dig något idag, så är det att "fatal" i dess meddelanden inte betyder "fatalt för projektet", det betyder "Jag kommer inte att gissa, säg uttryckligen till mig vad jag ska göra."