Git Rebase: Ein Leitfaden zum Rebasing von Branch-Commits

Git Rebase ist ein mächtiger Befehl, mit dem Entwickler den Commit-Verlauf anpassen, Änderungen von einem Branch auf einen anderen übertragen und eine saubere, lineare Projekt-Historie beibehalten können. In diesem Artikel wird erklärt, wie man Branch-Commits in Git rebasen kann.

Die Kurzfassung

Wenn Sie Git bereits kennen und nur eine schnelle Referenz zu den wichtigsten Rebase-Befehlen benötigen, finden Sie hier die wichtigsten Beispiele:

# Wende deine Branch-Commits auf die aktuelle main an
$ git switch feature   ## Wechsel zum Feature-Branch
$ git rebase main      ## Rebase der Commits auf den main-Branch

# Interaktiv die letzten 3 Commits bearbeiten (edit, squash, reorder)
$ git rebase -i HEAD~3

# Lokale Commits beim Pull mit Remote-Änderungen kombinieren (sauberere Historie)
$ git pull --rebase origin main

# Nach dem Rebase die angepasste Historie pushen
$ git push --force-with-lease  ## Sicherer als --force

Git Rebase verstehen

Beim Rebase werden Commits von einem Quell-Branch genommen und oben auf einen Ziel-Branch angewendet. Dadurch entsteht eine klare Historie ohne unnötige Merge-Commits. Die Commits bleiben inhaltlich gleich, erhalten aber neue IDs, da Git auf Basis der alten Commits neue erstellt.

Befehls-Syntax

git rebase [OPTIONEN] [UPSTREAM [BRANCH]]

• [OPTIONEN]: Bestimmen, wie der Befehl arbeitet. Weitere Details später im Artikel.
• UPSTREAM: Branch, auf den die Commits angewendet werden.
• [BRANCH]: Branch, dessen Commits verschoben werden. Standardmäßig der aktuelle Branch.

Befehls-Nutzung

Wechseln Sie auf den Branch, den Sie rebasen möchten:

$ git switch feature-branch

Wenden Sie die Commits des Feature-Branches auf den main-Branch an:

$ git rebase main

Bereinigen Sie Commits interaktiv vor dem Rebase:

$ git rebase -i

Pushen Sie Ihren Branch (wenn er vorher noch nie gepusht wurde):

$ git push

Falls der Branch schon vor dem Rebase gepusht wurde, nutzen Sie Force-Push (da sich die Historie geändert hat):

$ git push --force-with-lease

Hinweis: Mit --force-with-lease statt --force wird verhindert, dass Sie die Arbeit anderer versehentlich überschreiben.

Git Rebase vs. Git Merge

git rebase schreibt die Commit-Historie neu, indem Commits zwischen Branches verschoben werden. git merge hingegen erstellt einen neuen Commit, der die Änderungen zweier Branches zusammenführt. Die Historie bleibt dabei unverändert.

Nutzen Sie Merge für geteilte Branches und Rebase, um die Historie von lokalen oder Feature-Branches aufzuräumen, bevor Sie sie mergen.

Wann sollte man Rebase nutzen?

• Wenn Sie eine klare, lineare Historie wünschen.
• Wenn Sie unnötige Merge-Commits vermeiden möchten.
• Wenn Sie Ihre Änderungen vor dem Push auf den neuesten Stand von main bringen wollen.

Git Merge

Mit Git Merge werden Änderungen von einem Branch in einen anderen übernommen. Dabei entsteht ein Merge-Commit, der die Historien beider Branches bewahrt. So bleibt nachvollziehbar, wie sich die Entwicklung entwickelt hat.

Wechseln Sie in den main-Branch:

$ git switch main

Führen Sie den Feature-Branch in main zusammen und erstellen Sie bei Bedarf einen Merge-Commit:

$ git merge feature-branch

Arten von Git Rebase

Interaktives Rebase

Mit einem interaktiven Rebase können Sie Commits bearbeiten, löschen, zusammenfassen oder neu anordnen. Diese Methode ist ideal, um eine unübersichtliche Commit-Historie aufzuräumen, bevor Sie in ein gemeinsames Repository pushen.

Starten Sie ein interaktives Rebase der letzten drei Commits:

$ git rebase -i HEAD~3

Im Editor erscheint eine Liste wie diese:

pick  a1b2c3d  Login-Funktion hinzufügen
pick  b2c3d4e  Login-Fehler beheben
pick  c3d4e5f  Login-Design aktualisieren

Sie können pick ersetzen durch:

• reword: Commit-Nachricht ändern
• edit: Den Commit anpassen
• squash: Mit vorherigem Commit zusammenfassen
• drop: Commit entfernen

Nicht-interaktives Rebase

Dies ist der Standardmodus, wenn Sie git rebase ohne zusätzliche Optionen ausführen. Die Commits werden in der gleichen Reihenfolge auf einen anderen Branch angewendet, ohne dass eine interaktive Bearbeitung möglich ist. Dies eignet sich, um einen Feature-Branch mit dem Basis-Branch aktuell zu halten.

Rebasen Sie Commits auf den main-Branch:

$ git rebase main

Auto-Merge Rebase

Mit der Option --autostash legt Git automatisch nicht gespeicherte Änderungen beiseite, bevor das Rebase startet, und stellt sie danach wieder her. Dadurch werden Fehler durch ungespeicherte Änderungen verhindert.

Lokale Änderungen stagen, rebasen und danach automatisch wiederherstellen:

$ git rebase main --autostash

Häufig genutzte Konfigurationsoptionen

Nachfolgend die am häufigsten verwendeten Optionen für git rebase:

• –interactive (-i): Öffnet einen Editor, um Commits manuell zu ändern, neu anzuordnen, zusammenzufassen oder zu entfernen.
• –skip: Überspringt den aktuellen Commit (meist einer mit Konflikten) und setzt das Rebase fort.
• –continue: Führt das Rebase fort, nachdem Konflikte gelöst und Änderungen gestaged wurden.
• –abort: Bricht das Rebase ab und setzt den Branch in den ursprünglichen Zustand zurück.
• –autostash: Speichert nicht-committete lokale Änderungen automatisch zwischen und stellt sie nach dem Rebase wieder her.
• –onto <newbase>: Verschiebt einen Commit-Bereich auf einen neuen Basis-Commit, wird in erweiterten Szenarien genutzt.

Fazit

In diesem Artikel haben Sie gelernt, wie man Git-Commits sowohl interaktiv als auch nicht-interaktiv rebasen kann und welche Unterschiede es zwischen Rebase und Merge gibt. Mit diesen Techniken können Sie eine saubere Commit-Historie beibehalten, unnötige Merge-Commits vermeiden und die Zusammenarbeit effizienter gestalten. Weitere Details finden Sie in der offiziellen Git-Dokumentation.