So beheben Sie den „Git Push Rejected Non-Fast-Forward“-Fehler

Der FehlerAktualisierungen wurden abgelehnt, da die Remote-Version Arbeit enthält, über die Sie lokal nicht verfügen (ein Fehler, der kein Fast-Forward ist) bedeutet, dass jemand Commits an den Remote-Zweig gepusht hat, den Sie nicht haben. Git blockiert Ihren Push, um ein Überschreiben ihrer Arbeit zu verhindern. Hier erfahren Sie, wie Sie das Problem sicher lösen können.

Was dieser Fehler bedeutet

$ git push origin main
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the remote contains work that
hint: you do not have locally. This is usually caused by another
hint: repository pushing to the same ref.

Jemand (oder Sie von einem anderen Computer) hat Commits an den Remote-Zweig gepusht, nachdem Sie das letzte Mal gezogen haben. Ihre lokale Niederlassung und die Remote-Filiale sind auseinandergegangen. Git lässt Sie nicht pushen, weil es ihre Commits verwerfen würde.

Fix 1: Ziehen, dann drücken (zusammenführen)

# Fetch and merge the remote changes into your local branch
git pull origin main

# This creates a merge commit combining their work and yours.
# Resolve any conflicts if they occur, then:
git push origin main

Dies ist die sichere Standardeinstellung. Es integriert die Remote-Commits über einen Merge-Commit mit Ihren, dann ist Ihr Push erfolgreich.

Fix 2: Pull mit Rebase (Cleaner History)

# Replay YOUR commits on top of the remote's - linear history, no merge commit
git pull --rebase origin main

# If conflicts occur during rebase, resolve them, then:
git add 
git rebase --continue

# Then push
git push origin main

Durch die Neubasierung erhalten Sie einen saubereren, linearen Verlauf ohne Merge-Commit. Viele Teams bevorzugen dies. Ihre Commits werden zusätzlich zur neuesten Remote-Arbeit wiedergegeben.

Fix 3: Zuerst abrufen und überprüfen (vorsichtiger Ansatz)

# See what's on the remote before integrating
git fetch origin

# Compare your branch with the remote
git log HEAD..origin/main    # commits on remote you don't have
git log origin/main..HEAD    # your commits not on remote

# Then choose to merge or rebase
git merge origin/main        # or: git rebase origin/main
git push origin main

Legen Sie eine Standard-Pull-Strategie fest

# Configure how git pull behaves (avoids the "divergent branches" warning)

# Merge (default) - creates merge commits
git config --global pull.rebase false

# Rebase - linear history
git config --global pull.rebase true

# Fast-forward only - fail if not possible (forces you to decide)
git config --global pull.ff only

Wenn Sie SICHER sind, dass Sie (gefährlich)

# ⚠️ ONLY if you're certain the remote commits should be discarded
# (e.g., your own feature branch nobody else uses)

# --force-with-lease is safer than --force:
# it fails if the remote changed since your last fetch
git push --force-with-lease origin my-feature-branch

# ❌ NEVER force push to shared branches (main, develop)
# It permanently deletes other people's commits
git push --force origin main   # DON'T do this on shared branches

überschreiben möchten Warnung: Durch das erzwungene Pushen auf einen gemeinsam genutzten Zweig werden die Commits anderer Personen zerstört. Erzwingen Sie Push nur auf Ihre eigenen Feature-Branches, an denen sonst niemand arbeitet, und bevorzugen Sie--force-with-lease.

Den Unterschied verstehen

# Before: your local and remote have diverged
#   A---B---C (your local main)
#        #         D---E (remote main - someone else's commits)

# git pull (merge) creates:
#   A---B---C---F (merge commit)
#        \     /
#         D---E

# git pull --rebase creates (cleaner):
#   A---B---D---E---C' (your C replayed on top)

Häufig gestellte Fragen

F: Sollte ich eine Zusammenführung oder ein Rebase durchführen, um das Problem zu beheben?
A: Merge (Git Pull) ist die sichere Standardeinstellung und behält den genauen Verlauf bei. Rebase (git pull –rebase) sorgt für einen saubereren linearen Verlauf. Für gemeinsam genutzte Zweige funktioniert beides; Für Ihre eigenen Feature-Branches vor einem PR sorgt Rebase für Ordnung im Verlauf. Befolgen Sie die Konventionen Ihres Teams.

F: Warum kann ich Push nicht einfach erzwingen?
A: Durch das erzwungene Pushen in einen freigegebenen Zweig werden die von anderen gepushten Commits dauerhaft gelöscht – Sie würden deren Arbeit verlieren. Erzwingen Sie Push (mit –force-with-lease) nur auf Ihre eigenen Feature-Branches, die sonst niemand verwendet. Erzwingen Sie niemals den Haupt- oder Entwicklungsvorgang.

F: Was macht –force-with-lease, was –force nicht tut?
A: --force-with-lease prüft, ob sich die Fernbedienung seit Ihrem letzten Abruf nicht geändert hat – wenn jemand in der Zwischenzeit gedrückt hat, schlägt der Vorgang fehl, anstatt ihn zu überschreiben. Es handelt sich um ein Sicherheitsnetz, das verhindert, dass Commits, die Sie nicht gesehen haben, versehentlich zerstört werden. Ziehen Sie es immer dem einfachen –force vor.

F: Nach dem Ziehen sind Zusammenführungskonflikte aufgetreten. Was nun?
A: Öffnen Sie die Konfliktdateien, lösen Sie die Konflikte (wählen Sie aus, welche Änderungen beibehalten werden sollen), danngit add die aufgelösten Dateien. Für eine Zusammenführunggit commit. Für eine Rebase:git rebase --continue. Dann drücken.

F: Wie vermeide ich diesen Fehler in Zukunft?
A: Ziehen Sie, bevor Sie mit der Arbeit beginnen und bevor Sie schieben. Kommunizieren Sie mit Ihrem Team darüber, wer woran arbeitet. Ziehen Sie bei aktiven gemeinsam genutzten Zweigen häufig, um auf dem neuesten Stand zu bleiben und Abweichungen zu minimieren.

Fazit

Die Nicht-Fast-Forward-Push-Ablehnung bedeutet, dass die Fernbedienung Commits hat, die Sie lokal nicht haben – Git schützt diese Commits, indem es Ihren Push blockiert. Die Lösung ist einfach:Ziehen Sie zuerst die Remote-Änderungen (git pullzum Zusammenführen odergit pull --rebasefür einen saubereren Verlauf), lösen Sie alle Konflikte und drücken Sie dann. Erzwingen Sie niemals das Pushen auf gemeinsam genutzte Branches – es zerstört die Arbeit anderer. Wenn Sie Ihren eigenen Feature-Zweig überschreiben müssen, verwenden Sie--force-with-lease (sicherer als--force). Um diesen Fehler zu vermeiden, ziehen Sie häufig und kommunizieren Sie mit Ihrem Team. Wenn Sie verstehen, dass Git Commits schützt, die Sie noch nicht gesehen haben, ist die Lösung intuitiv: Integrieren Sie die Remote-Arbeit und führen Sie dann einen Push durch.