Sieh Rebase und Merge nebeneinander in einem Live-Commit-Graphen, plane ein interaktives Rebase mit pick, squash, fixup und drop und lerne, wie du mit dem Reflog abbrichst oder rückgängig machst.
git rebase spielt die Commits deines Branches erneut auf einem anderen Commit ab und erzeugt so eine gerade Historie statt eines Merge-Commits. Führe auf deinem Feature-Branch git rebase main aus, löse eventuelle Konflikte und dann git rebase --continue. Mit git rebase -i kannst du Commits squashen, umformulieren oder verwerfen, mit git rebase --abort brichst du ab.
Die Rebase-Befehle, die du am häufigsten tippst
Rebase ist der Git-Befehl, vor dem die meisten Leute am meisten Respekt haben, vor allem weil er Commits umschreibt. Der Graph unten zeigt genau, was sich bei Merge im Vergleich zu Rebase ändert, mit dem Planer kannst du ein interaktives Rebase an Beispiel-Commits ausprobieren, und die letzten Abschnitte behandeln Konflikte, die eine Regel, die dein Team schützt, und wie du einen Branch nach einem missglückten Rebase zurückholst.
Merge behält die echte Historie und fügt einen Merge-Commit hinzu, was für gemeinsam genutzte Branches am sichersten ist. Rebase ergibt eine gerade Linie, die sich leichter lesen und mit bisect durchsuchen lässt, und passt zu deinem eigenen Feature-Branch vor dem Review. Viele Teams rebasen privat und mergen öffentlich.
Wenn es noch läuft, stellt git rebase --abort alles wieder her. Wenn es schon fertig ist, führe git reflog aus, suche den Eintrag direkt vor dem Start des Rebase und setze mit git reset --hard auf diesen Hash zurück. Direkt nach einem Rebase zeigt auch ORIG_HEAD auf die alte Spitze, sofern kein anderer Befehl es geändert hat.
Rebase keine Commits, auf denen andere bereits ihre Arbeit aufgebaut haben. Rebase erzeugt neue Commits mit neuen Hashes, daher haben alle, die noch die alten besitzen, am Ende doppelte Historie und verwirrende Konflikte.
Beide falten einen Commit in den darüberliegenden ein. squash öffnet den Editor, damit du beide Nachrichten kombinieren kannst; fixup verwirft die Nachricht des eingefalteten Commits und behält die frühere. fixup -C behält stattdessen die Nachricht des eingefalteten Commits.
Jeder Commit wird auf der neuen Basis erneut angewendet, und ein Commit, der dieselben Zeilen wie die Basis geändert hat, lässt sich nicht automatisch anwenden. Bearbeite die Datei, führe git add darauf aus und dann git rebase --continue. Pro erneut abgespieltem Commit kann ein Konflikt auftreten.
git rebase -i öffnet eine Todo-Liste mit einer Zeile pro Commit, der älteste steht oben. Ändere das Wort am Zeilenanfang, speichere, schließe den Editor, und Git arbeitet die Liste von oben nach unten ab.
Befehle der Todo-Liste in git rebase -i
Zuerst fetchen, damit main aktuell ist, dann rebasen, Konflikte lösen und den umgeschriebenen Branch sicher pushen.
Suche die Zeile direkt vor dem Beginn des Rebase und setze den Branch darauf zurück.
--onto nimmt drei Punkte: die neue Basis, die alte Basis und den Branch. Nur die Commits nach der alten Basis werden verschoben.
feature-b wurde von feature-a aus begonnen. Damit landen nur die eigenen Commits von feature-b auf main.
Merge oder Rebase: was mit der Historie passiert
Wähle, wie die Branches zusammengeführt werden
Merge
Rebase
Merge-Commit
Merge lässt F1 und F2 unverändert und fügt einen neuen Commit mit zwei Parents hinzu.
Rebase kopiert F1 und F2 auf M3. Die Kopien (markiert mit ') haben neue Hashes; die Originale bleiben zurück.
Planer für interaktives Rebase
Wähle für jeden Commit eine Aktion, den ältesten zuerst, und sieh dir die Todo-Liste und das Ergebnis an.
Aktion für Commit {n}
Todo-Liste, die Git öffnet
Historie nach dem Rebase
Die erste Zeile darf nicht squash oder fixup sein: Darüber gibt es keinen Commit zum Einfalten.
Alle Commits wurden verworfen. Der Branch würde auf seine Basis zeigen.
enthält {n} eingefaltete(n) Commit(s)
Nachricht bearbeitet
Kostenlos starten · Keine Kreditkarte nötig