Sie haben git pull ausgeführt, und statt der erwarteten Änderungen begrüßte Sie das Terminal mit einer roten Zeile: fatal: refusing to merge unrelated histories. Das Projekt wurde nicht aktualisiert, die Commits wurden nicht heruntergezogen, und Sie fragen sich, ob Sie das Repository beschädigt haben.

Nein, Sie haben es nicht beschädigt. Git weigert sich schlicht, zwei unabhängige Historien zu vermischen, und das ist beabsichtigtes Verhalten, kein Fehler. In fünf Minuten werden Sie nicht nur verstehen, warum dieser Fehler auftritt, sondern auch lernen, ihn in jeder Situation zu beheben: beim ersten Push, nach dem Verlust von .git und beim Zusammenführen unterschiedlicher Projekte.

💡 Schneller Überblick:

• Wann Git sich weigert, nicht verwandte Branches zusammenzuführen, und warum das korrekt ist
• Das Flag --allow-unrelated-histories, eine universelle Lösung für pull, merge und den ersten Push
• Schritt-für-Schritt-Szenarien: Klonen ohne Historie, neues Repository, Rebase und Force-Push
• Was zu tun ist, wenn das Flag nicht hilft, und wie Sie diesen Fehler künftig vermeiden

Was der Fehler bedeutet und warum Git ihn auslöst

Git verfolgt die Historie über eine Kette von Commits. Jeder Commit referenziert seinen Vorgänger und baut so einen Graphen auf, den Git nutzt, um zu verstehen, was woher stammt. Bei git merge sucht Git nach einem gemeinsamen Vorfahren zweier Branches und berechnet die Differenz davon ausgehend.

Doch manchmal existiert schlicht kein gemeinsamer Vorfahre. Zwei Commit-Graphen überschneiden sich nicht, wie zwei separate Projekte, die nie voneinander wussten. In einer solchen Situation weigert sich Git, die Historien blind zu vermischen, und gibt aus:

1
fatal: refusing to merge unrelated histories

Das ist kein Fehler im üblichen Sinne. Es ist ein Schutzmechanismus: Git teilt Ihnen mit: „Ich verstehe nicht, wie diese beiden Historien zusammenhängen, also rate ich nicht." Die Lösung existiert und ist ab Version 2.9.0 (veröffentlicht im Juni 2016) in Git integriert.

Zwei typische Szenarien, die zu dem Fehler führen

Erstes Szenario, Beschädigung oder Löschung des .git-Verzeichnisses. Sie haben ein Projekt geklont, mit dem Code gearbeitet, aber der .git-Ordner wurde gelöscht (versehentlich, durch Antivirensoftware oder beim Kopieren ohne versteckte Dateien). Git verliert die gesamte lokale Historie und behandelt Ihr Arbeitsverzeichnis bei git push oder git pull als völlig neues Projekt, das in keiner Beziehung zum Remote-Repository steht.

Zweites Szenario, ein neues Repository trifft auf ein bestehendes. Sie haben git init ausgeführt, lokal einige Commits hinzugefügt und dann versucht, ein Remote-Repository anzubinden, das bereits eine eigene Historie besitzt. Git sieht zwei unabhängige Commit-Graphen und weigert sich, sie zu vermischen. Das passiert häufig, wenn Sie ein Projekt von Grund auf neu starten und es dann zusätzlich zu einem bestehenden Repository auf GitHub hochladen möchten oder wenn Sie Code von einem Projekt in ein anderes übertragen.

Beide Szenarien werden durch denselben Mechanismus gelöst, aber bevor Sie ihn anwenden, sollten Sie verstehen, was genau Sie erreichen möchten: zwei Historien zu einer zusammenführen oder eine Historie vollständig durch eine andere ersetzen.

Lösung: das Flag --allow-unrelated-histories

Der Schlüssel zur Behebung ist das Flag --allow-unrelated-histories. Es weist Git ausdrücklich an: „Ich weiß, dass diese Branches keinen gemeinsamen Vorfahren haben, und ich möchte sie bewusst zusammenführen." Das Flag funktioniert mit beiden Hauptbefehlen, git pull und git merge.

**Für **git pull (der häufigste Fall):

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

Ersetzen Sie main durch Ihren Branch-Namen, falls dieser abweicht (master, develop usw.). Git erstellt einen Merge-Commit, der die beiden unabhängigen Historien verbindet. Es öffnet sich wahrscheinlich ein Editor für die Commit-Nachricht: Beschreiben Sie, warum Sie die Historien zusammenführen, speichern und schließen Sie den Editor.

**Für **git merge (wenn Branches lokal sind):

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

Nach erfolgreichem Merge fordert Git Sie auf, das Ergebnis zu pushen. Vergessen Sie das nicht:

1
git push origin main

Wichtige Nuance: --allow-unrelated-histories beseitigt keine Merge-Konflikte. Wenn beide Branches Dateien mit denselben Namen enthalten, verlangt Git weiterhin, dass Sie Konflikte manuell auflösen. Das Flag behandelt nur die Verbindung der Historien, nicht die Dateiinhalte.

Schritt-für-Schritt-Szenarien für verschiedene Situationen

Situation 1: erster Push in ein nicht leeres Remote-Repository

Sie haben ein Projekt lokal erstellt (git init → Commits), und auf GitHub existiert bereits ein Repository mit README.md und .gitignore. Ein direkter git push funktioniert nicht, weil der Remote-Branch Commits enthält, die Sie nicht haben.

Korrekte Abfolge:

Zuerst die Remote-Historie pullen und mit Ihrer lokalen zusammenführen:

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

Lösen Sie eventuelle Konflikte auf (meist README.md-Konflikte), erstellen Sie einen Merge-Commit, dann:

1
git push origin main

Situation 2: Wiederherstellung nach Verlust von.git

Der .git-Ordner ist gelöscht, aber das Arbeitsverzeichnis ist intakt. Sie können die Verbindung zum Remote-Repository wiederherstellen, ohne nicht committete Änderungen zu verlieren:

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

Der Befehl git reset --mixed synchronisiert den Git-Index mit dem Remote-Branch, lässt aber alle Ihre Arbeitsdateien unangetastet. Fügen Sie danach die Änderungen hinzu und erstellen Sie einen neuen Commit:

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

Dieser Ansatz ist --allow-unrelated-histories vorzuziehen, weil er keinen künstlichen Merge-Commit erzeugt und die Historie sauber hält.

Situation 3: Rebase mit nicht verwandten Historien

Auch der Befehl git rebase kann diesen Fehler auslösen, besonders bei Verwendung des Flags --preserve-merges (jetzt ersetzt durch --rebase-merges). Lösung: Fügen Sie --allow-unrelated-histories hinzu:

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

Aber seien Sie vorsichtig: Rebase schreibt die Historie um, und wenn jemand anderes mit diesem Branch arbeitet, bereiten Sie ihm Probleme. Bevorzugen Sie für gemeinsam genutzte Branches stets merge.

Was zu tun ist, wenn das Flag nicht hilft

Manchmal funktioniert --allow-unrelated-histories fehlerfrei, aber das Ergebnis ist nicht das, was Sie wollten.

Problem: Merge-Commit überfrachtet die Historie. Wenn Sie zwei große Projekte zusammengeführt haben, wird der Commit-Graph schwer lesbar. Ziehen Sie in diesem Fall eine Alternative in Betracht: die Übertragung von Dateien mit Erhalt der Historie mittels git format-patch und git am:

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

Problem: Nach dem Merge kompiliert das Projekt nicht. Das Zusammenführen nicht verwandter Historien kann zu doppelten Konfigurationsdateien, Abhängigkeitskonflikten oder inkompatiblen Paketversionen führen. Prüfen Sie nach --allow-unrelated-histories stets: Abhängigkeiten (npm install / composer install), Konfigurationsdateien (.env, config/), Pfade und Importe im Code. Lieber fünf Minuten in die Prüfung investieren, als sich später mit fehlschlagenden Builds in der CI herumzuschlagen.

Problem: Sie haben es sich anders überlegt. Sie können einen Merge nicht verwandter Historien auf dem Standardweg rückgängig machen: git reset --hard HEAD~1 (wenn Sie das Ergebnis noch nicht gepusht haben) oder git revert -m 1 HEAD (wenn Sie bereits gepusht haben).

So vermeiden Sie den Fehler in Zukunft

Drei einfache Regeln, die Ihnen diesen Fehler im Arbeitsalltag ersparen.

Löschen Sie .git nicht ohne absolute Notwendigkeit. Wenn Sie Code ohne Historie kopieren müssen, nutzen Sie git archive oder kopieren Sie Dateien bewusst unter Ausschluss des versteckten .git-Ordners, nicht versehentlich.

Erstellen Sie kein neues Repository innerhalb eines bestehenden. Wenn Sie einen Teil der Codebasis in ein separates Projekt auslagern müssen, nutzen Sie git subtree split oder git filter-branch (heute wird git filter-repo empfohlen). Diese Werkzeuge erhalten die Historie der benötigten Dateien, und Git weiß, woher sie stammen.

Prüfen Sie vor git init in einem Ordner mit Code stets, ob sich dort bereits ein Repository befindet: git status. Antwortet Git mit fatal: not a git repository, können Sie initialisieren. Zeigt es einen Status an, befinden Sie sich bereits in einem bestehenden Repository, und git init ist hier nicht nötig.

Für diejenigen, die gerade mit der Arbeit mit Git beginnen, empfehlen wir unseren Leitfaden „Git-Leitfaden für Einsteiger". Er führt Sie Schritt für Schritt durch SSH-Keys, Repository-Erstellung und den vollständigen GitHub-Workflow. Und falls Git noch nicht installiert ist, beginnen Sie mit dem Leitfaden „Git unter Windows installieren".

⁉️🤔 Häufig gestellte Fragen

Welche Git-Versionen unterstützen --allow-unrelated-histories?

Das Flag erschien in Git 2.9.0 (Juni 2016) und ist in allen nachfolgenden Versionen enthalten. Falls Ihre Git-Version älter ist, aktualisieren Sie sie: Der Befehl git --version zeigt die aktuelle Version an, und git update-git-for-windows (unter Windows) oder der Paketmanager Ihres Systems aktualisiert auf die aktuelle Version. Der einfachste Weg, die Git-Version zu prüfen, ist der Befehl git --version im Terminal. Mitte 2026 ist der aktuelle Zweig 2.48+. Wenn Sie unter Windows arbeiten und Git vor langer Zeit installiert wurde, laden Sie einen frischen Installer von git-scm.com herunter; die automatische Aktualisierung funktionierte in alten Versionen unzuverlässig.

Kann ich das Flag direkt mit git push verwenden?

Nein, git push akzeptiert --allow-unrelated-histories nicht. Push erzeugt keinen Merge, es sendet nur bestehende Commits. Der Fehler „unrelated histories" beim Push bedeutet, dass Ihr lokaler Branch und der Remote-Branch auf Historie-Ebene auseinandergelaufen sind. Lösung: zuerst git pull --allow-unrelated-histories, Konflikte auflösen und erst dann git push. Formal funktioniert --allow-unrelated-histories mit git fetch + git merge und mit git pull (das intern fetch + merge ausführt). Push bleibt ein separater Vorgang, den Sie nach erfolgreichem Merge durchführen. Versuchen Sie nicht, dies mit --force zu umgehen, Sie verlieren sonst die Commits anderer Personen auf dem Remote-Repository.

Was ist besser für eine saubere Historie: Merge oder Rebase?

Für das Verbinden nicht verwandter Historien definitiv merge. Rebase schafft in diesem Kontext mehr Probleme, als es löst: Es versucht, Commits eines Branches auf einen anderen wiederzugeben, aber ohne gemeinsamen Vorfahren führt das bei jedem Commit zu Konflikten. Merge mit --allow-unrelated-histories tut genau das Nötige: Es schafft einen Verbindungspunkt zwischen zwei Graphen, wonach die Historie vereinheitlicht ist. Ausnahme: wenn Sie die Historie bewusst umschreiben wollen und genau wissen, was Sie tun. Zum Beispiel bei der Übertragung von Code von einem Repository in ein anderes mit Bereinigung alter Commits. In diesem Fall kann git rebase --allow-unrelated-histories sinnvoll sein, aber für die tägliche Arbeit wählen Sie Merge.

Ich habe den .git-Ordner verloren, aber ich habe nicht committete Änderungen. Werde ich sie verlieren?

Nein, Sie werden sie nicht verlieren. Der .git-Ordner selbst enthält nur die Historie und Git-Metadaten, nicht aber Ihre Arbeitsdateien. Alle geänderten, neuen und selbst nicht committeten Dateien bleiben im Arbeitsverzeichnis unangetastet erhalten. Die Wiederherstellung ist oben in „Situation 2" beschrieben: git init → git remote add → git fetch → git reset --mixed. Entscheidender Punkt: Verwenden Sie exakt --mixed, nicht --hard. Das Flag --mixed setzt den Index zurück, bewahrt aber alle Änderungen in den Dateien. Wenn Sie unsicher sind, erstellen Sie vor der Wiederherstellung eine Sicherungskopie des gesamten Projektordners. Das dauert zehn Sekunden und schließt das Risiko eines Datenverlusts in jeder nicht standardgemäßen Situation vollständig aus.

Der Fehler tritt beim Klonen über eine IDE auf. Ist das dasselbe Problem?

Ja, dasselbe. Einige IDEs (zum Beispiel PHPStorm, Visual Studio, ältere Versionen von IntelliJ) initialisieren beim Erstellen eines Projekts aus einer Vorlage ein neues Git-Repository und versuchen dann, ein Remote anzubinden. Das ist exakt das zweite Szenario vom Anfang des Artikels. Die Lösung ist dieselbe: Öffnen Sie ein Terminal im Projektordner und führen Sie git pull origin main --allow-unrelated-histories aus. Nach dem manuellen Merge übernimmt die IDE den neuen Zustand automatisch. Aktualisieren Sie einfach das Projektfenster oder klicken Sie im Git-Panel auf Aktualisieren.

Sollten Sie den Fehler „unrelated histories" fürchten?

Nein. Dies ist einer der sichersten Git-Fehler. Er beschädigt keine Daten, löscht keine Dateien und hindert Sie nicht daran, weiterzuarbeiten. Das Flag --allow-unrelated-histories ist keine Krücke oder Notlösung, sondern eine dokumentierte Fähigkeit, die von den Git-Entwicklern speziell für Fälle hinzugefügt wurde, in denen Sie bewusst zwei unabhängige Historien verbinden möchten.

Wenn Sie diesen Befehl beherrschen, gewinnen Sie ein mächtiges Werkzeug: Sie können jetzt Projekte beliebigen Isolationsgrads zusammenführen, Code zwischen Repositories übertragen und die Arbeit nach dem Verlust von .git wiederherstellen, und das alles ohne Panik und ohne das Repository von Grund auf neu zu erstellen. Wenn Git Ihnen heute etwas beigebracht hat, dann dies: „fatal" in seinen Meldungen bedeutet nicht „fatal für das Projekt", sondern „Ich rate nicht, sagen Sie mir ausdrücklich, was zu tun ist."