Squash-Commits, die bereits in Git gepusht wurden

Dieser Artikel beschreibt den Prozess des Squashing von Commits, die wir bereits in das Remote-Repository gepusht haben. Wir quetschen Commits zu einem zusammen, um die Unordnung in unserem Repository zu reduzieren.

Um Commits zu squashen, führen wir im interaktiven Modus einen git rebase durch.

Squash-Commits, die bereits in Git gepusht wurden

Um den Kontext zu vereinfachen, simulieren wir ein Szenario, in dem wir nach dem Pushen von Änderungen einige Commits in einem zusammenfassen müssen.

Zuerst werden wir unsere aktuellen Änderungen in das Remote-Repository übertragen.

$ git push origin Dev2.1

Dieser Befehl wird alle Änderungen an unseren Remote-Zweig Dev2.1 übertragen.

Wir können den Befehl git rebase bis zum 5. Commit ausführen.

$ git rebase -i HEAD~5

Ausgang:

Um unsere Commits zu squashen, ersetzen wir am Anfang der Commits pick durch squash und beenden die Rebase.

Wir können den Befehl git log ausführen, um unseren Commit-Verlauf anzuzeigen.

Der Versuch eines Pushs führt zu einem Fehler, wie unten gezeigt.

Der Fehler ist selbsterklärend; wir werden nicht viel darauf eingehen.

Wir müssen einen Push erzwingen, nicht mit dem Flag --force, sondern wie unten gezeigt.

$ git push origin +Dev2.1

Ausgang:

Werfen wir einen kurzen Blick auf das Remote-Repo auf GitHub.

Wir verwenden das + vor dem refspec, um in unserem Fall einen Push auf den Zweig Dev2.1 zu erzwingen.

Zusammenfassend lässt sich sagen, dass Ihnen nach dem Squashing von Commits, die Sie bereits auf die Fernbedienung gepusht haben, ein normaler git push nichts nützt.

Sie werden in einer lästigen Schleife stecken bleiben, in der Git von Ihnen verlangt, dass Sie ziehen, bevor Sie pushen. Das Hinzufügen des + vor Ihrem Zweig im Befehl git push origin löst das Problem.