Der Fehler„Fatal: Weigerung, nicht zusammenhängende Geschichten zusammenzuführen“ wird angezeigt, wenn Sie versuchen, ein Git-Repository zusammenzuführen oder daraus abzurufen, das keinen gemeinsamen Vorfahren mit Ihrem aktuellen Zweig hat. Dies geschieht am häufigsten, wenn Sie mit einer README-Datei ein neues Repo auf GitHub erstellen und versuchen, ein lokales Projekt zu pushen, oder wenn Sie zwei völlig separate Repositories kombinieren. Hier ist jedes Szenario und die richtige Lösung.
📋 Table of Contents
- Warum dieser Fehler auftritt
- Szenario 1: Repo auf GitHub mit README erstellt, Local hat bereits Commits
- Szenario 2: Kombination zweier separater Repositorys
- Szenario 3: Git Pull, nachdem Repo neu erstellt wurde
- Der richtige Weg: Erstellen Sie keine README-Datei auf GitHub, wenn Sie lokalen Code haben
- Wann ist –allow-unrelated-histories sicher?
- Repository-Beziehungen prüfen
- Häufig gestellte Fragen
- Fazit
Warum dieser Fehler auftritt
Git verfolgt den Verlauf über eine Kette von Commits. Wenn zwei Repos nie einen gemeinsamen Commit geteilt haben (unabhängige Historien), weigert sich Git seit Git 2.9 standardmäßig, sie zusammenzuführen – es geht davon aus, dass Sie einen Fehler gemacht haben. Der Fehler sieht folgendermaßen aus:
$ git pull origin main
fatal: refusing to merge unrelated histories
Oder beim Zusammenführen:
$ git merge origin/main
fatal: refusing to merge unrelated histories
Szenario 1: Repo auf GitHub mit README erstellt, Local hat bereits Commits
Dies ist die häufigste Ursache. Sie haben ein GitHub-Repo mit einer README-Datei (oder einer Lizenz) initialisiert und dann versucht, Ihr lokales Projekt zu pushen. Ihr lokaler Server hat Commits; GitHub hat einen Commit (die README-Datei) – keinen gemeinsamen Verlauf.
# ✅ Option 1: Force push (destroys the README commit — simplest)
git push -u origin main --force
# WARNING: Only use if nobody else has cloned the repo
# and you don't mind losing the GitHub-created README
# ✅ Option 2: Allow merge (keeps both, creates merge commit)
git pull origin main --allow-unrelated-histories
# Resolve any conflicts (often just README vs your code)
git push origin main
# ✅ Option 3: Rebase (cleanest linear history)
git fetch origin
git rebase origin/main
# Resolve any conflicts
git push origin main
Szenario 2: Kombination zweier separater Repositorys
Sie haben zwei Repositories und möchten eines mit dem anderen zusammenführen (z. B. indem Sie ein Frontend-Repo und ein Backend-Repo zu einem Monorepo kombinieren).
# Add the second repo as a remote
git remote add other-repo https://github.com/user/other-repo.git
git fetch other-repo
# Merge allowing unrelated histories
git merge other-repo/main --allow-unrelated-histories
# All files from both repos are now in working tree
# Commit the merge
git commit -m "Merge other-repo into monorepo"
Um die Dateien des zweiten Repos in einem Unterverzeichnis zu behalten (sauberer für Monorepos):
# Better approach: move the second repo's files to a subdirectory first
git fetch other-repo
git checkout -b temp-branch other-repo/main
# Move all files to a subdirectory
mkdir backend
git ls-files | xargs -I{} git mv {} backend/{}
git commit -m "Move to backend/ subdirectory"
# Merge back into main
git checkout main
git merge temp-branch --allow-unrelated-histories
Szenario 3: Git Pull, nachdem Repo neu erstellt wurde
Ein Teammitglied hat das Remote-Repository gelöscht und neu erstellt und dabei seinen Verlauf gelöscht. Ihre lokale Kopie verfügt über Commits, die neue Fernbedienung nicht.
# Check what happened
git log --oneline -5 # your local history
git log --oneline origin/main -5 # remote history
# If you want to keep your local history (usually correct)
git push origin main --force-with-lease
# --force-with-lease is safer than --force: fails if remote has
# commits you haven't fetched (prevents accidental overwriting)
# If you want the new remote's history (abandon local)
git fetch origin
git reset --hard origin/main
Der richtige Weg: Erstellen Sie keine README-Datei auf GitHub, wenn Sie lokalen Code haben
Die eigentliche Lösung ist die Prävention. Wenn Sie ein vorhandenes lokales Projekt haben:
# 1. Create repo on GitHub WITHOUT initializing (no README, no .gitignore)
# 2. Add remote and push
git init # if not already a repo
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/user/repo.git
git push -u origin main # no conflicts because remote is empty
Wann ist –allow-unrelated-histories sicher?
# Safe scenarios:
# - Initializing a project that was created with a README on GitHub
# - Combining unrelated repos intentionally into a monorepo
# - Recovering from an accidental repo recreation
# Unsafe scenarios:
# - You don't understand why the histories are unrelated
# - The remote was supposed to be a fork of your local (shouldn't be unrelated)
# - Two branches of the same project (investigate root cause instead)
git merge other-branch --allow-unrelated-histories
Repository-Beziehungen prüfen
# See if two commits share ancestry
git merge-base --is-ancestor commit1 commit2
echo $? # 0 = ancestor, 1 = not ancestor
# See all commit ancestry graph
git log --oneline --graph --all
# Find common ancestor (if any)
git merge-base branch1 branch2
Häufig gestellte Fragen
F: Ist –allow-unrelated-histories gefährlich?
A: Es kann zu einem verwirrenden Verlauf führen, ist aber nicht destruktiv – Sie können eine Zusammenführung jederzeit rückgängig machen. Das größere Risiko besteht darin, es zu verwenden, wenn Sie es nicht sollten (wenn Repos zusammenhängen sollten und etwas schief gelaufen ist). Verstehen Sie, warum sie nichts miteinander zu tun haben, bevor Sie die Flagge verwenden.
F: Was ist der Unterschied zwischen –allow-unrelated-histories und –force?
A: --allow-unrelated-histories führt die beiden Historien zusammen (beide bleiben im Git-Protokoll). --force überschreibt einen Verlauf mit dem anderen (die überschriebenen Commits verschwinden von der Fernbedienung).
F: Wie konfiguriere ich Git so, dass immer unabhängige Historien zugelassen werden?
A: Tun Sie das nicht – die Standardablehnung besteht aus gutem Grund. Beheben Sie stattdessen die Grundursache. Wenn Sie Repos regelmäßig kombinieren, verwenden Sie Git-Submodule oder ein Monorepo-Tool wie Turborepo.
F: Kann ich eine versehentliche Zusammenführung von –allow-unrelated-histories rückgängig machen?
A: Ja:git revert -m 1 MERGE_COMMIT_HASH um die Zusammenführung rückgängig zu machen, odergit reset --hard HEAD~1 falls Sie es noch nicht getan haben.
F: Dies ist in einem Team-Repository passiert. Wie kann ich das Problem beheben, ohne andere zu beschädigen?
A: Erzwingen Sie nicht das Pushen freigegebener Zweige. Verwenden Siegit merge origin/main --allow-unrelated-histories um einen Merge-Commit zu erstellen, Konflikte zu lösen und normal zu pushen. Alle anderen könnengit pull normalerweise.
Fazit
Der Fehler „Weigerung, nicht verwandte Historien zusammenzuführen“ entsteht fast immer dadurch, dass ein GitHub-Repo mit einer anfänglichen README-Datei erstellt wird, bevor Ihr lokales Projekt gepusht wird. Die sauberste Lösung: Push mit--force wenn sonst niemand die Fernbedienung hat, oder verwenden Sie--allow-unrelated-histories um beide Historien zusammenzuführen. Best Practice für die Zukunft: Erstellen Sie leere GitHub-Repos und pushen Sie lokalen Code, anstatt Repos auf GitHub zu initialisieren, wenn Sie bereits über lokale Commits verfügen.
🔗 Share this article
✍️ Leave a Comment