In diesem Artikel
Du möchtest ein Website-Update auf dem Server einspielen, aber git pull --ff-only bricht ab. Git hat damit oft keinen Downloadfehler gemeldet: Lokal und auf dem Remote existieren inzwischen unterschiedliche neue Commits. Ein reines Vorspulen kann diese beiden Entwicklungen nicht verbinden.
Genau das passierte am 6. Oktober 2026 bei meinem worldnode-Checkout. Der Server hatte einen eigenen World-Observer-Dashboard-Commit, während auf GitHub eine Website-Änderung angekommen war. Der anschließend ausgeführte Rebase war erfolgreich. Dieses konkrete Beispiel macht die Begriffe greifbar.
Was Fast-forward eigentlich bedeutet
Ein Fast-forward verschiebt den lokalen Branchzeiger entlang einer bereits vorhandenen Historie nach vorn. Dafür darf es keine zusätzliche lokale Entwicklung geben, die mit dem Ziel verbunden werden müsste.
Wenn lokal ein eigener Commit entsteht und das Remote parallel einen anderen bekommt, liegen beide hinter demselben gemeinsamen Ausgangspunkt. Weder ersetzt der eine den anderen noch sind sie automatisch in einer einzigen Reihenfolge angeordnet. --ff-only verlangt genau den einfachen Fall und bricht sonst ab.
| Zustand | Was ein einfacher Pull benötigt |
|---|---|
| Nur Remote hat neue Commits | Fast-forward kann möglich sein |
| Nur lokal gibt es neue Commits | Remote ist möglicherweise bereits enthalten |
| Beide Seiten haben eigene Commits | Eine bewusste Integration |
| Uncommittete lokale Dateien | Zuerst ihren Zustand und Zweck klären |
Erst den Arbeitszustand prüfen
Für meinen Website-Pfad lautet die lesende Prüfung:
git -C /srv/www/dennishilk.github.io status
Der Pfad gilt für meinen Server. Passe ihn an deinen Checkout an. Ein sauberer Arbeitsbaum ist eine gute Voraussetzung für die folgende Integration. Uncommittete Änderungen verdienen zuerst eine Entscheidung: bewusst committen oder gezielt sichern. Automatisch alles zu stagen kann fremde oder sensible Dateien aufnehmen.
Hole danach die Remote-Informationen:
git -C /srv/www/dennishilk.github.io fetch origin main
fetch aktualisiert die bekannten Remote-Daten, integriert sie aber noch nicht in deinen aktuellen Arbeitsbaum. Prüfe, ob origin tatsächlich das gewünschte Repository bezeichnet. Ein alter origin/main-Stand kann einen Historienvergleich irreführend machen.
Lokal und Remote vergleichen
Der Vergleich zeigt nur die Commits, die jeweils einer Seite fehlen:
git -C /srv/www/dennishilk.github.io log --oneline --left-right -15 HEAD...origin/main
In meinem damaligen Verlauf standen diese zwei Einträge:
< 843d8827 world-observer: publish dashboard 2026-10-06
> 3fa0277a Restore homepage styling and unify the site language toggle
< gehörte zur lokalen Seite HEAD, > zu origin/main. Die Hashes und Titel sind der beobachtete Fall vom 6. Oktober, keine erwartete Ausgabe jedes Servers. Damit war klar: Der lokale Dashboard-Commit sollte erhalten bleiben und die Website-Änderung dazukommen.
Sieh dir bei Bedarf die betroffenen Änderungen an, bevor du einen Integrationsweg auswählst. Commit-Titel allein erklären nicht alle Dateien und Auswirkungen.
Merge und Rebase als zwei Integrationswege
Ein Merge verbindet die Historien und behält die vorhandenen Commit-Identitäten. Bei tatsächlich auseinanderlaufender Entwicklung entsteht gewöhnlich ein zusätzlicher Merge-Commit. Das ist passend, wenn die ursprüngliche verzweigte Historie erhalten bleiben soll.
Ein Rebase setzt lokale Commits auf die ausgewählte neue Basis. Ihre Änderungen werden erneut angewendet und erhalten dabei neue Commit-Identitäten. Im Serverfall lag der lokale Dashboard-Commit anschließend hinter dem Website-Update.
| Entscheidung | Typischer Bezug |
|---|---|
| Merge | Bereits gemeinsam verwendete Historie erhalten |
| Rebase | Eigene, noch nicht geteilte Commits auf die neue Basis setzen |
--ff-only |
Nur den einfachen Vorspulfad erlauben |
Ein bereits veröffentlichter Commit gehört nicht beiläufig in einen Rebase. Andere Rechner können darauf aufbauen. Der gewählte Serverweg war passend für den dortigen lokalen Commit; daraus folgt keine Regel, jede divergierende gemeinsame Historie umzuschreiben.
Den lokalen Ausgangspunkt behalten und rebasen
Nach sauberem Status kannst du vor einer Integration einen neuen lokalen Sicherungszeiger setzen. Verwende einen bislang freien Namen:
git -C /srv/www/dennishilk.github.io branch backup-vor-update-20261008
Diese Referenz bewahrt den damaligen Commit als Vergleichspunkt. Sie sichert keine uncommitteten Dateien und ist kein unabhängiges Datenbackup.
Der im konkreten Serverfall gewählte Integrationsbefehl lautete:
git -C /srv/www/dennishilk.github.io rebase origin/main
Wenn die Änderungen zusammenpassen, beendet Git den Vorgang erfolgreich. Prüfe anschließend git status, die relevante Website und die Historie. Erfolgreiche Git-Integration bedeutet noch nicht, dass jede Anwendungsfunktion getestet ist.
Konflikte verständlich lösen oder abbrechen
Falls Git anhält, zeigt git status die Konfliktdateien. Lies beide Änderungen und entscheide anhand des gewünschten Endzustands. Für HTML ist es wichtig, nicht nur Konfliktmarker zu entfernen, sondern auch Navigation, Sprachlinks und Struktur zu bewahren.
Markiere jede bewusst gelöste Datei einzeln als erledigt. PFAD/ZUR/DATEI ist ein Platzhalter:
git -C /srv/www/dennishilk.github.io add PFAD/ZUR/DATEI
Setze den laufenden Rebase fort:
git -C /srv/www/dennishilk.github.io rebase --continue
Willst du stattdessen zum Start dieses laufenden Rebase zurückkehren:
git -C /srv/www/dennishilk.github.io rebase --abort
--abort gehört zu einem noch laufenden Rebase. Es ist kein universeller Rückspulbefehl nach jedem abgeschlossenen Update. Ein --skip würde eine Änderung überspringen; verwende es nicht bloß, um eine Konfliktmeldung loszuwerden.
Regelmäßige Server-Updates und Grenzen
Wenn der Server bewusst eigene noch nicht geteilte Dashboard-Commits erzeugt, ist ein ausdrücklich gewählter Pull mit Rebase nachvollziehbar:
git -C /srv/www/dennishilk.github.io pull --rebase origin main
Auch dieser Befehl kann an Konflikten oder lokalen Dateien stoppen. Er ist keine Aufforderung zu reset --hard, Force-Push oder pauschalem Löschen. Prüfe die Änderung, bewahre sinnvolle lokale Arbeit und teste das Ergebnis.
Quellen
- Git pull: Fetch und gewählter Integrationsweg.
- Git rebase: neue Basis, Konflikte und Abbruch.
- Git merge und Git log.
- Website-Repository.
Der Serverfall stammt vom 6. Oktober 2026; Referenzen geprüft am 8. Oktober 2026. Die Befehle gehören in den jeweils geprüften Checkout.