Git-Repository auftrennen

Im Ver­lauf eines Pro­jek­tes kann es sin­nvoll sein, gewach­sene Repos­i­to­ry-Struk­turen aufzuräu­men und einzelne Teile als eigen­ständi­ge Repos her­auszutren­nen.

Für einen der­ar­ti­gen Split hält Git die Option “fil­ter-branch” bere­it.

Hin­weis: Vor Beginn der Oper­a­tion sollte es selb­stver­ständlich sein, geeignete Back­ups des Repos­i­to­ries zu haben. Und: Alles auf eigene Gefahr! 😉

Anhand eines Beispiels wird das ganze etwas deut­lich­er:

Nen­nen wir das ursprüngliche Repo “Orig­i­nal”, darin befind­lich ver­schiedene Dateien sowie zwei Verze­ich­nisse “Sub1” und “Sub2”, jew­eils auch mit Dateien oder Verze­ich­nis­sen gefüllt.

Ziel ist, ein neues Repo zu erstellen, das nur “Sub1” bein­hal­tet und übri­gen Bal­last abwirft.

Dazu — um das orig­i­nale Repo zu erhal­ten — klo­nen wir das Repo zunächst an eine andere Stelle, z.B. “Kopie”. Auch hier sind damit die entsprechen­den Dateien und Verze­ich­nisse des Orig­i­nals enthal­ten. (Auch bei mehreren Branch­es.)

Im Verze­ich­nis “Kopie” wird dann z.B. in der Kom­man­dozeile fol­gen­des Git-Kom­man­do aus­ge­führt:

git filter-branch --subdirectory-filter Sub1 --prune-empty -- --all

Was sagt der Befehl? “fil­ter-branch” ist für das umschreiben des Ver­sionsver­laufs zuständig und die bei­den zuge­höri­gen Optio­nen “sub­di­rec­to­ry-fil­ter” und “prune-emp­ty” fil­tern die Com­mits auf ein Unter­verze­ich­nis (hier “Sub1”) bzw. ignori­eren leere Com­mits. Die let­zte Angabe “all” bezieht sich (durch die bei­den Striche ohne Option vorher) auf git und gibt an, dass alle Branch­es gefiltert wer­den sollen.

Das Ergeb­nis ist wie gewün­scht: Am Ende befind­en sich im Ord­ner “Kopie”, also dem ober­sten Verze­ich­nis des kopierten Repos­i­to­ries, die Dateien, die vorher im Ord­ner “Sub1” waren, alle anderen Dateien und Verze­ich­nisse wur­den ent­fer­nt.

Hin­weis: Das neue Repo ist nach der Oper­a­tion nicht mehr ohne weit­eres mit dem ursprünglichen kom­pat­i­bel.

Noch ein Hin­weis: Git macht bei fil­ter-branch auch intern ein Back­up, d.h. die Größe des Verze­ich­niss­es auf dem Daten­träger wird noch nicht unmit­tel­bar klein­er. Dazu ist eine Möglichkeit, das Repo zu klo­nen: Im Klon ist das interne Back­up nicht mehr enthal­ten. Außer­dem bietet sich an, den Garbage Col­lec­tor aufzu­rufen.

Quellen: Git-Man­u­al, GitHub Help

Leave a Reply

Your email address will not be published. Required fields are marked *