Wie erhält der neu gekaufte Laptop schnellstmöglich Kopien aller aktiv genutzten Git-Repositories? Ein Meta-Repository führt eine Projektliste und Perl-Skripte automatisieren alle Aufspür- und Klonvorgänge.

© Claudia Hautumm, Pixelio.de

Das Versionskontrollsystem Git walzt mit seiner Performance und überragenden Branch-Strategie Oldtimer wie CVS, Subversion oder Perforce platt und mancher fragt sich, wie er vor der Erfindung dezentralisierter Versionskontrollsysteme überhaupt Software entwickeln konnte.

Repository-Sammlungen

Allerdings konzentriert sich Git meist auf ein einzelnes Projekt, Subprojekte unterstützt es allenfalls rudimentär. Aktive Entwickler erzeugen oder klonen deswegen im Lauf der Zeit Dutzende von Git-Repositories, die oft auf unterschiedlichen Servern liegen. Dieses Verfahren funktioniert ohne großen Aufwand - solange der Entwickler nicht den Rechner wechselt und plötzlich alles neu klonen muss. Nach dem Kauf eines neuen Laptops oder dem Umzug auf einen neuen Entwicklungsdesktop wäre es hilfreich, würde er dort gleich eine Kopie aller aktiv bearbeiteten Projekte vorfinden.

Oft lassen sich Computer zudem Gruppen zuordnen, die unterschiedliche Repositories brauchen: Auf dem Laptop verbietet sich vielleicht aus Platzgründen ein Git-Repository mit großen Bildern, während auf dem Rechner des Arbeitgebers private Inhalte nichts zu suchen haben. Eine Konfigurationsdatei, irgendwo im Internet abgelegt, könnte die Zugangsdaten der gewünschten Repositories speichern. Deren Werte ändern sich häufig, denn neue Projekte kommen hinzu und alte fallen weg. Den Überblick behält natürlich ein Versionskontrollsystem wie Git, also ein Meta-Repository!

Erfundenes Format

Als Format für die Konfigurationsdatei bietet sich das sowohl für menschliche Wesen als auch für Computer leicht lesbare YAML-Format an. Der spezielle Dialekt soll GMF (Git Meta Format) heißen, und die Konfigurationsdateien tragen ».gmf« als Endung.

Abbildung 1 zeigt ein Beispiel. Der erste Eintrag verweist auf ein privat gehostetes Repository, das auf dem fiktiven, per SSH-Zugang gesicherten Server »private.server.com« liegt. Der zweite Eintrag zeigt auf das offizielle Git-Repository des Perl-5-Kerns, auf dem sich alle Check-ins finden, seit Larry Wall im Jahre 1987 die erste Version von Perl freigab. Beide Repository-Locators bearbeitet der Befehl »git clone« direkt und legt auf Kommando ein lokales Directory mit einer Kopie des jeweiligen Repository an.

Abbildung 1: In der Datei »gitmeta.gmf« im Repository »gitmeta« irgend-wo im Internet liegen die Metadaten aller aktiv bearbeiteten Git-Repositories des Users.

Natürlich könnte die GMF-Datei einfach alle aktiv bearbeiteten Repositories in einer solchen Liste aufführen, doch sehr aktive Entwickler empfänden das dauernde manuelle Einfügen von neuen oder das Löschen von abgewrackten Projekten wohl als zu mühselig.

Führt jemand zum Beispiel ein Dutzend Projekte auf Github.com oder in einem Verzeichnis auf einem per SSH zugänglichen Server, könnte er diese Eingriffe einsparen, wenn es das Meta-Repository verstünde, diese Sammlungen automatisch zu interpretieren. Anweisungen wie beispielsweise "Nimm alle Repositories in diesem Verzeichnis" oder "Alle auf Github liegenden Repositories" sollte das Meta-Repository schon verstehen.

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.

Wie erhält der neu gekaufte Laptop schnellstmöglich Kopien aller aktiv genutzten Git-Repositories? Ein Meta-Repository führt eine Projektliste und Perl-Skripte automatisieren alle Aufspür- und Klonvorgänge.