Ich verwalte die Dateien dieses Blog in git. Damit sind alle Änderungen gespeichert und kann ich jederzeit experimentieren, ohne Datenverlust befürchten zu müssen. Ein wenig Verwaltungsaufwand in der Kommandozeile ist damit verbunden. Und manchmal geht was schief.

Vornehmlich am späteren Abend, wenn ich müde einen Artikel geschrieben habe und den nur noch schnell committen will. Schwupps fehlt eine Datei im Commit, oder ist eine zu viel drin, oder habe ich ärgerliche Rechtschreibfehler in die Commit-Nachricht eingebaut. Natürlich könnte ich alles über weitere Commits korrigieren, aber dann wären die Fehler für immer in der Versionsgeschichte und würden das Log unübersichtlich machen. Außerdem sieht das nicht schön aus.

Zum Glück rechnet git mit solchen Fehlern. Ist etwas schiefgegangen, reicht es in den meisten Fällen, einfach git status einzutippen. git schlägt dann vor, wie die letzte Änderung rückgängig gemacht werden kann, z.B. so:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

Ich kenne zwei Szenarien, in denen git status mir keine Hinweise gibt:

  • Eine verhunzte Commit-Nachricht: Die kann ich über git commit --amend nachträglich korrigieren.
  • Einen Commit rückgängig machen: Das kann ich über git reset HEAD~.

Beides funktioniert naturgemäß nicht mehr so gut, wenn ich das Repository bereits mittels git push mit einem entfernten Repository synchronisiert habe.

Zur weiteren Lektüre in einer stillen Stunde notiere ich mir einen Abschnitt aus der deutschen Ausgabe des Pro-Git-Buchs und den äußerst vertiefenden Artikel Reset Demystified im git-scm-Blog.