Git-Historie neu-schreiben (nicht nur) mit Filter-Branch

Posted on Do 16 März 2017 in Git

Nach längerer Pause zum Thema Versionsverwaltung mit Git geht es an dieser Stelle ein wenig weiter. Git-Repositorys beinhalten bekanntlich ihre vollständige Historie, so dass alle Änderungen immer in der Historie verbleiben. Problematisch wird das aber, wenn Zugangsdaten im Repository gelandet sind. Ein bloßes Entfernen funktioniert da leider nicht, da die Historie ja vollständig da ist.

Ein einfaches Beispiel sieht man etwa, wenn man bei GitHub nach „delete id_rsa“ sucht, was ein privater SSH-Key ist, der nicht eigentlich in ein Git-Repository landen sollte. Genauso findet man auf GitHub Commit-Messages mit dem Inhalt „remove password“.

Wenn man die entsprechenden Passwörter oder SSH-Private-Keys ändert bzw. ersetzt, dann muss man natürlich nicht viel mehr in dem Git-Repository ändern. Anders sieht es aus, wenn die Datei bzw. die Zeilen vollständig entfernt werden soll. Die Historie muss dafür (maximal) vollständig angepasst werden, was für jede Person, die mit dem Repository arbeitet, heißt, dass es vermutlich am einfachsten ist, das Projekt einmal neu zu klonen.

Abhilfe um gleich eine Vielzahl von Commits anzupassen bietet das Subkommando filter-branch. Dies kann nicht nur zum Entfernen von Passwörtern oder anderen Credentials dienen, sondern auch, wenn etwa große Binärdateien im Repository sind, die entfernt werden sollen.

Um das Verfahren auszuprobieren, kann man sich ein einfaches Repository anlegen, in dem zahlreiche Commits erzeugt werden, um dieses Repository dann aufzuräumen.

$ mkdir test-repo
$ for i in {1..500}; do echo "Commit $i" >> index; git add -A; git commit -m "Commit $i"; done

Diese Bash-For-Schleife legt im Test-Repository die Datei index an und schreibt in jedem Durchlauf den Durchlaufzähler in die Datei, mit dem Wort "Commit" vorne dran. Nach jeder Zeile wird dann ein Commit mit selbigen Inhalt in der Commit-Message gespeichert.

Das Repository wäre somit vorbereitet. Filter-Branch hat diverse Filter, die man anwenden kann. Eines ist etwa der tree-filter, mit dem man dateibasiert arbeitet.

Eine einfache Methode eine Datei aus allen Commits wäre es, ein rm -f index auszuführen, was in jedem Commit die Datei entfernen würde. Händisch wäre das ja zu aufwändig, weshalb man folgenden Befehl ausführen kann:

$ git filter-branch --tree-filter 'rm -f index' HEAD

Statt die Datei zu entfernen, kann man auch Inhalte der Datei verändern, etwa mit sed. Dazu muss dann der Befehl entsprechend angepasst werden. Es gibt auch noch weitere Filter, wie etwa der subdirectory-filter. Dieser kann genutzt werden, um ganze Unterverzeichnisse in ein eigenes Repository zu überführen. Die Historie des restlichen Repositorys wird dabei ignoriert, sofern sie nicht relevant ist. Wesentlicher Vorteil ist dabei, dass die vollständige Historie eines Subdirectories erhalten bleibt, sodass man auch nach dem Extrahieren frühere Änderungen nachvollziehen kann.

Alternative: BFG Repo-Cleaner

Eine Alternative zum reinen Filter-Branch ist der BFG Repo-Cleaner. Im Gegensatz zu Filter-Branch ist die Nutzung deutlich einfacher und es soll auch schneller sein. Das Tool ist in Java geschrieben und besitzt ein paar nette Features, die man sich bei Filter-Branch erstmal selbst zusammen schreiben müsste. Ein Beispiel ist etwa die automatische Entfernung von Dateien, die größer sind als eine spezifizierte Größe. Dazu besitzt bfg den Parameter --strip-blobs-bigger-than. Das vorherige Beispiel mit dem Löschen der Datei funktioniert zwar prinzipiell mit Filter-Branch auch einfach, allerdings beachtet es immer nur den aktuellen Pfad. Wenn etwa eine oder mehrere zu löschende Dateien im Repository zuvor herum geschoben wurde, dann hilft bfg mit dem Parameter --delete-files schon viel mehr, da es immer die Dateien mit den entsprechenden Namen löscht.

Für viele dürfte der BFG Repo-Cleaner ein einfaches Interface bieten, um die Historie vollständig anzupassen und trotzdem viel und auch schneller zu arbeiten. In der Regel erfolgt die Nutzung von Filter-Branch auch häufig nur einmalig, weshalb sich einige Sachen nur mit gewissen Aufwand durchführen lassen, die mit BFG einfacher und wohl auch schneller gehen. Bedacht werden sollte aber immer, dass sehr viele Commits angepasst werden. Man sollte dies nur tun, wenn es wirklich nötig ist und auch die Mitarbeiter entsprechend vorher informieren, damit kein bzw. nur kurz ein kaputtes Repository lokal vorhanden ist!

Vielen Dank an Dirk der mich auf BFG Repo-Cleaner hinwies. Mehr zu Git findet sich auf meinem Blog in der Git-Kategorie.

Comments


There are no comments yet.

Add a Comment

You can use the Markdown syntax to format your comment.