Ein Rebase setzt die eigenen Commits auf einen anderen Stand neu auf. Statt zwei Stränge zusammenzuführen, nimmt Git jeden Commit des Zweigs einzeln und wendet ihn auf den neuen Ausgangspunkt an. Das Ergebnis ist eine gerade Linie.
- Rebase
Das Neuaufsetzen eigener Commits auf einen anderen Stand.
Beispiel: „Vor dem Pull Request noch ein Rebase, damit die Geschichte gerade bleibt.“Englisch to rebase heißt die Grundlage wechseln. Der Zweig bekommt einen neuen Ausgangspunkt.
Wichtig: Die Commits werden dabei **neu geschrieben**. Sie haben hinterher andere Prüfsummen, sind also technisch andere Commits mit demselben Inhalt.
Was ein Rebase gegenüber einem Merge ändert
Die Geschichte. Im Arbeitsverzeichnis steht am Ende beidemal dasselbe; unterschiedlich ist nur, was später darüber zu lesen ist. Der Merge zeigt die Gabel, der Rebase zeigt eine Reihe.
Welches besser ist, hängt davon ab, was die Geschichte leisten soll. Wer später nachvollziehen will, welche Commits zu welcher Aufgabe gehörten, braucht die Gabel. Wer eine lesbare Reihe will, nimmt den Rebase.
Warum ein Rebase auf gemeinsamen Zweigen gefährlich ist
Weil die alten Commits verschwinden und durch neue ersetzt werden. Wer den Zweig schon geholt hat, hat die alten; beim nächsten Holen passen beide Geschichten nicht mehr zusammen.
Daraus folgt die verbreitete Regel: Rebase nur auf Zweigen, die niemand sonst benutzt. Danach braucht es einen Force Push, und auch der ist dort unbedenklich.
Was ein Rebase sonst noch kann
In seiner interaktiven Form ist er das Aufräumwerkzeug: Commits zusammenfassen, Nachrichten nachbessern, die Reihenfolge ändern oder einen Commit ganz herausnehmen.
Das ist der Grund, warum viele Teams ihn vor dem Pull Request verlangen. Aus fünfzehn Zwischenständen mit Nachrichten wie „fix“ werden drei Commits, die ein Mensch lesen kann.