Repos aufteilen für Git

Im ersten Schritt legen die Verantwortlichen die Struktur der späteren Git-Repositories fest. Viele Unternehmen teilen dabei ihr großes, zentrales Repository in mehrere handlichere auf. Univention spendierte beispielsweise der Dokumentation und dem Quellcode jeweils ein eigenes Git-Repository.

Das FreeBSD-Team orientierte sich an seinen drei Teilprojekten, die aus Dokumentation, dem Quellcode für das Basissystem und den zusätzlichen Paketen (Ports) besteht. Die Verantwortlichen entschieden sich übrigens zunächst dafür, die Dokumentation zu migrieren: Als kleinstes Projekt ließ sich mit ihm die Umstellung sehr gut durchspielen und ausprobieren.

Besteht die Software aus sehr vielen Komponenten und wählt man für jede ein eigenes Repository, so lassen sich die vielen entstandenen Repositories nicht mehr effizient mit Standard-Werkzeugen verwalten. Bei Raritan entschied man sich deshalb, den Quellcode in ein Haupt-Repository zu stecken, während Third-Party-Code jeweils in eigenen Git-Repositories landete.

Im nächsten Schritt entsteht ein Backup des ursprünglichen Repositorys, auf dem im Folgenden alle Arbeiten und Tests stattfinden. Bis der Migrationsprozess steht, kann so gleichzeitig das alte Repository in Betrieb bleiben und das Tagesgeschäft weiterlaufen. Erst wenn die tatsächliche Konvertierung ansteht, sperrt man den Schreibzugriff auf das originale Repository und führt dann mit einer neuen Kopie die tatsächliche Migration durch.

History kürzen

Im einfachsten Fall exportiert man den Quellcode aus dem alten Versionssystem und checkt den Quellcode dann in ein neues Git-Repository ein. Diesen Weg wählte der für seine Jira-Produktfamilie bekannte Cloud-Betreiber Atlassian. Dabei gehen allerdings die History sowie die alte Struktur in Form von Branches und Tags verloren. Im Gegenzug verläuft die Konvertierung besonders schnell und problemlos ab. Bei Atlassian dauerte die Migration nach eigenen Angaben gerade einmal fünf Stunden.

In der Regel sollen jedoch die Commits und Branches erhalten bleiben, um auch später noch den Grund für eine Implementierung oder Änderung nachschlagen zu können. Bei einem sehr großen Repository sollten Unternehmen dennoch darüber nachdenken, die History zu kürzen: Aufgrund der Arbeitsweise von Git besitzt später jeder Entwickler eine komplette Fassung des Git-Repositorys auf seiner Festplatte.

Durch das Löschen beziehungsweise einer Teilübernahme der bestehenden History bleibt das Git-Repository relativ klein. Ergänzend bietet es sich an, nicht mehr benötigten Quellcode auszumisten und aus dem Repository zu nehmen. Ein durch diese Maßnahmen geschrumpftes Repository beschleunigt auch ganz nebenbei die eigentliche Migration.

Aus diesen Gründen räumte auch Raritan seinen Quellcode vor der Konvertierung auf. Matthias Höpfner von der Softwareberatung Höpfner hat sich bei der Migration von mehreren Subversion-Repositories in einem großen deutschen Unternehmen auf die History des jeweils letzten Jahres konzentriert. Atlassian nutzte die Gunst der Stunde und formatierte auch gleich noch den Quellcode an einigen Stellen um.