git ready

Commits mit Rebase neu Anordnen

Ein der weitesgehenden Verwendungen von git rebase -i ist das Neuordnen von Commits. Aber bitte, BITTE verwendet rebase nicht bei Commits, die bereits öffentlich verteilt worden sind. Wenn du mit anderen Entwicklern zusammenarbeitest, führt das zu Merges, nicht mehr als fast-forward zusammengeführt werden können und das bedeutet meist Kopfschmerzen für alle Beteiligten. Ja, der Befehlt erlaubt es, die Historie umzuschreiben und sollte nur durchgeführt werden, wenn die Commits noch nur auf dem lokalen System liegen.

Das war es mit den Warnungen und wir kommen zum Punkt. Das Szenario handelt davon, dass die Reihenfolge von Commits geändert werden soll. Vielleicht sollen bestimmte Änderungen weiter unten in der Historie erscheinen oder aus irgend einem Grund macht der dritte Commit an der ersten Stelle einfach mehr Sinn. Das wollen wir jetzt einfach mal machen. Angenommen, unsere Historie sieht wie folgt aus:

Wir fangen mit git rebase -i HEAD~3 an. Der $EDITOR öffnet sich mit ungefähr dem folgenden Text:

pick 4c39bca gemspec tweak
pick 85409cf Version bump to 0.4.1
pick eb32194 Regenerated gemspec for version 0.4.1

# Rebase 60709da..eb32194 onto 60709da
#
# Commands:
#  p, pick = use commit
#  e, edit = use commit, but stop for amending
#  s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Neu Anordnen ist so einfach wie die unterschiedlichen ‘pick’ Befehle herumzubewegen. Wenn der erste mit dem letzten Commit getauscht werden soll, sieht das so aus:

pick eb32194 Regenerated gemspec for version 0.4.1
pick 85409cf Version bump to 0.4.1
pick 4c39bca gemspec tweak
...

$ git rebase -i HEAD~3
Successfully rebased and updated refs/heads/test.

Nach dem Speichern der Datei wird hoffentlich alles glatt gehen. Wenn nicht, gibt es wahrscheinlich einen netten Merge, der versorgt werden muss. Wenn es zu häßlich wird, sich darum zu kümmern, führt ein git rebase --abort zum Ausgangspunkt zurück. Keine Sorge bezüglich Datenverlusten, da reflog immer zur Seite steht, um alles zurückzuholen, was benötigt werden könnte. Wie erwartet, zeigt die Historie die Commits in umgedrehter Reihenfolge.

Ein kurzer Hinweis: Das Datum der einzelnen Commits ist noch im Original vorhanden, d.h. nicht umgedreht. Insbesondere für andere Mitarbeiter am Repository kann das ein wenig komisch aussehen. Neu Anordnen ist wahrscheinlich nützlicher, sobald es mit anderen Aufgaben aus dem interaktiven Rebase kombiniert wird, z.B. Squashing oder Commit-Nachrichten bearbeiten. Wenn das Neu Anordnen geholfen (oder auch geschmerzt) hat, lass es in den Kommentaren wissen.