Git Squash verstehen – Commits vor dem Merge aufräumen

Beim Entwickeln entstehen oft viele Zwischenstände: „WIP“, „Fix Lint“, „Ups, Tests“, „nochmal“. Das ist normal und sogar hilfreich, solange in Ruhe gearbeitet wird. Spätestens beim Merge in den Hauptbranch wünscht sich das Team aber meist eine lesbare Historie. Genau dafür ist Git Squash gedacht: Mehrere Commits werden zu einem einzigen zusammengefasst – die Änderungen bleiben, die Historie wird aufgeräumter.

Wichtig ist dabei: Squashen verändert die Commit-Historie. Das ist auf Feature-Branches meist okay, auf gemeinsam genutzten Branches kann es Ärger machen. Wer die Regeln kennt, kann Squash gezielt einsetzen und Pull Requests deutlich angenehmer machen.

Was bedeutet Squashen in Git eigentlich?

Mehrere Commits werden zu einem neuen Commit

Beim Squashen werden mehrere aufeinanderfolgende Commits so „zusammengeklappt“, dass am Ende ein einzelner Commit entsteht. Dieser neue Commit enthält alle Änderungen der ursprünglichen Commits, hat aber eine neue Commit-ID (Hash). Die alten Commit-IDs werden damit praktisch ersetzt.

Squash ist keine neue Änderung, sondern neue Historie

Der Code-Zustand nach dem Squash ist (idealerweise) identisch zu vorher. Es geht nicht um neue Features, sondern um eine verständlichere Geschichte: Statt zehn Mini-Commits gibt es einen Commit, der klar beschreibt, was das Feature liefert.

Wann ist Squashen sinnvoll – und wann nicht?

Typische Fälle, in denen Squash hilft

• Ein Feature-Branch enthält viele kleine Fixes, die für Außenstehende nicht relevant sind (z. B. „typo“, „Lint“, „Fix failing test“).
• Ein Pull Request soll später leicht zurückgerollt werden können: ein Feature, ein Commit (oder wenige).
• Ein Team legt Wert auf eine „saubere“ Historie, in der jeder Commit eine klare Aussage hat.

Situationen, in denen Squash riskant ist

• Auf Branches, auf denen mehrere Personen parallel arbeiten und bereits Commits gezogen haben. Durch das Umschreiben der Historie entstehen Konflikte und „verlorene“ Referenzen.
• Wenn einzelne Commits bewusst getrennt bleiben sollen, z. B. „Refactoring“ getrennt von „Feature“, damit Reviews und spätere Fehleranalyse einfacher sind.
• Wenn Releases/Hotfixes einzelne Schritte nachvollziehbar brauchen (je nach Prozess).

Faustregel: Commit-Historie umschreiben ist meist okay, solange der Branch nur lokal oder exklusiv im eigenen Pull Request genutzt wird. Sobald andere darauf aufbauen, braucht es klare Absprachen.

Squash-Optionen im Alltag: Rebase, Merge-Squash, Plattform

Interaktiver Rebase: flexibel und präzise

Der Klassiker ist interaktiver Rebase. Damit lässt sich sehr genau steuern, welche Commits zusammengeführt werden und welche Commit-Message am Ende steht. Das ist ideal, wenn ein Branch „aufgeräumt“ werden soll, bevor er als Pull Request finalisiert wird.

Squash beim Merge: schnell, aber weniger Kontrolle

Viele Plattformen (z. B. GitHub/GitLab) bieten „Squash and merge“ an. Dabei wird der gesamte Pull Request als ein Commit in den Zielbranch übernommen. Das ist bequem und verhindert, dass alle Zwischenstände im Hauptbranch landen. Allerdings ist die Kontrolle geringer: Wer zwei bis drei sinnvolle Commits behalten will (z. B. „Feature“ und „Migration“), muss eher über Rebase arbeiten.

Was unterscheidet Squash von Rebase generell?

Squashen ist eine spezielle Form des „Historie umschreiben“. Rebase kann noch mehr: Commits neu anordnen, einzelne Commits aufteilen oder auch entfernen. Wer Rebase grundsätzlich sauber einsetzen will, findet eine passende Vertiefung hier: Git Rebase verständlich erklärt.

Praktische Schrittfolge: Feature-Branch vor dem Merge squashen

Kurz und sicher: Vorher Branch-Stand prüfen

Bevor die Historie geändert wird, lohnt sich ein kurzer Check: Ist alles committed? Läuft die Test-Suite? Sind keine uncommitted Änderungen offen? Damit sinkt das Risiko, dass beim Aufräumen etwas durcheinander gerät.

Schritt für Schritt mit interaktivem Rebase

Ein typischer Ablauf auf einem Feature-Branch sieht so aus (Begriffe: „HEAD“ = aktueller Stand, „upstream“ = Branch, auf den aufgebaut wird):

• Aktuellen Stand holen (z. B. main aktualisieren) und prüfen, ob der Branch sauber darauf basiert.
• Interaktiven Rebase für die letzten N Commits starten (N so wählen, dass die „WIP“-Commits enthalten sind).
• In der Liste die Commits, die zusammen sollen, als „squash“ (oder „fixup“) markieren.
• Commit-Message aufräumen: eine aussagekräftige Nachricht schreiben, optional mit kurzen Bullet-Points im Text.
• Tests laufen lassen und den Branch aktualisiert pushen (meist mit Force Push, aber bewusst).

Beim Push ist der Knackpunkt: Weil Squash neue Commit-IDs erzeugt, ist oft ein Force Push nötig. In Teams ist „force push“ nicht automatisch schlecht, aber es braucht Regeln: nur auf eigenen Feature-Branches, nicht auf gemeinsam genutzten Branches.

Entscheidungshilfe: Squash, Rebase oder Merge-Commit?

Je nach Ziel passt eine andere Strategie. Diese kleine Entscheidungshilfe hilft bei der Auswahl:

• Ist es ein kleiner Feature-Branch, der am Ende „als Paket“ in main soll?
  • Ja: Squash (per Plattform oder Rebase) ist oft passend.
  • Nein: weiter.
• Sollen zwei bis drei logisch getrennte Commits im Zielbranch erhalten bleiben (z. B. „DB-Migration“ getrennt von „Code“)?
  • Ja: Interaktiver Rebase, aber nur teilweise squashen.
  • Nein: weiter.
• Ist die Historie des Feature-Branches bereits gut lesbar und jeder Commit sinnvoll?
  • Ja: Normaler Merge (oder Rebase ohne Squash) kann besser sein.
  • Nein: Squash reduziert Rauschen.

Commit-Nachrichten nach dem Squash: so bleiben sie hilfreich

Was eine gute Message leisten soll

Nach dem Squash trägt ein einzelner Commit mehr Bedeutung. Eine gute Message beantwortet in einfacher Sprache: Was wurde geändert und warum? Statt „Update“ ist „Benutzerprofil: Validierung und Speichern verbessert“ hilfreicher.

Praktische Vorlage

• Erste Zeile: kurzer Titel, der den Nutzen beschreibt.
• Optional darunter: 2–5 Stichpunkte, was konkret dazugehört (z. B. „API-Route ergänzt“, „UI-Fehlerzustände verbessert“).

Wer Commit-Nachrichten im Team generell vereinheitlichen will, kann sich an einem klaren Schema orientieren. Passend dazu: Git Commit Messages im Team sauber schreiben.

Häufige Stolperfallen beim Squashen (und wie sie sich vermeiden lassen)

Konflikte während des Rebases

Beim Rebase können Konflikte auftreten, weil Git Commits neu „abspielt“. Das ist kein Zeichen, dass etwas kaputt ist. Wichtig ist, Konflikte in Ruhe zu lösen und anschließend den Rebase fortzusetzen. Wenn Konflikte häufig sind, hilft oft: erst den Branch mit dem Zielbranch synchronisieren, dann squashen.

Pull Request wird „unübersichtlich“ nach Force Push

Ein Force Push kann dazu führen, dass Reviews alte Kommentare verlieren oder sich auf Zeilen beziehen, die nicht mehr exakt passen. Deshalb ist Squashen meist am sinnvollsten, wenn das Review weitgehend durch ist und nur noch aufgeräumt werden soll.

Squash vs. Reset/Revert: nicht verwechseln

Squash dient dem Aufräumen. Wer Änderungen rückgängig machen will, nutzt andere Werkzeuge. Für das saubere Zurücknehmen von Commits (je nach Situation) hilft dieser Artikel: Git Reset vs. Revert.

Mini-Guide für den Team-Alltag: klare Regeln, weniger Stress

In vielen Teams entstehen Probleme nicht durch Git selbst, sondern durch fehlende Absprachen. Ein einfacher, praxistauglicher Rahmen kann so aussehen:

Kompakt zum Mitnehmen

• Squash ist ideal, um „Arbeits-Commits“ in sinnvolle Einheiten zu verwandeln.
• Historie umschreiben nur dort, wo niemand anderes darauf aufbaut.
• Nach dem Squash eine klare Message schreiben – sie ist später der Einstieg in die Änderung.
• Vor dem Push Tests laufen lassen, damit der neue Einzel-Commit wirklich stabil ist.