Was haben die englische Sprache und eine Software gemeinsam? Knapp ein Drittel der gesamten Weltbevölkerung spricht Englisch. Auch das Erlernen ist vergleichsweise leicht. Doch wer die Sprache perfektionieren möchte, stößt dann auf die wirklich kniffligen Feinheiten und Nuancen des Englischen.

Ganz ähnlich verhält es sich im Bereich der Softwareentwicklung mit dem derzeit extrem populären Open-Source-Versionisierungstool Git: Der Einstieg in die Software ist leicht, die grundlegenden Funktionen für den Alltag einfach zu erlernen. Gerade junge Entwickler, die frisch von der Uni kommen, sind oft von vornherein an den Umgang mit Git gewöhnt. Als OpenSource-Lösung sind auch die Investitionskosten für den Einstieg zunächst gering und die Software lässt sich schnell und einfach aufsetzen. Insgesamt bietet sie Einzelentwicklern oder kleinen bis mittleren Teams damit genau die schnelle, flexible Versionskontrolle, die diese im Arbeitsalltag wünschen und benötigen.

Komplexe Entwicklungsprojekte führen zu Problemen

Steigen mit der Zeit jedoch die Größe und Komplexität eines Entwicklungsprojektes, nimmt damit auch der Schwierigkeitsgrad der Git-Nutzung deutlich zu. Besonders brisant ist diese Problematik, da sich gerade in den letzten Jahren die Art und Weise der Softwareentwicklung grundlegend verändert hat. Im Zuge der Digitalisierung und des Internets der Dinge dringt Software in nahezu alle Bereiche unseres Lebens vor - der Bedarf an Software, wie auch die Anforderungen daran, steigen kontinuierlich an.
In vielen Fällen sind Projekte heutzutage bereits von Vornherein komplexer, die daran beteiligten Teams größer und nicht selten gar über den gesamten Globus verteilt. Entwicklungs-Repositorys, also die zentralen Datenspeicher, in denen alle für die Entwicklung einer Software relevanten Dateien lagern, umfassen heute schnell mehrere Gigabyte - selbst in kleinen Unternehmen. In Szenarien wie diesen jedoch stößt Git an seine Grenzen.

Am effizientesten arbeitet Git mit kleinen bis mittelgroßen Repositorys. Überschreiten Projekte eine bestimmte Größenordnung - in der Regel ein bis zwei Gigabyte -, wird die Arbeit mit Git schnell unhandlich. Der Grund hierfür liegt in seiner Architektur: Ein Git-Repository ist intern als Baum aufgebaut, bei dem jede Verzweigung eine bestimmte Änderung an den Entwicklungsdateien repräsentiert.
Kryptographisch gesichert ist diese Änderung in Form eines Hashs, der sich wiederum auf die vorausgegangene Änderung bezieht. Um den aktuellen Entwicklungsstand darzustellen, erfordert jedes Repository demnach das Vorhandensein der gesamten Projekthistorie. Da diese somit bei zentralen Aktionen wie dem Herunterladen ("Klonen") eines Repositorys vollständig mitübertragen werden muss, verlangsamt sich ein solcher Prozess von wenigen Sekunden auf Minuten oder gar Stunden.

Lässt sich das Projekt dann nicht einfach verkleinern? Leider nein. Denn hierfür bietet Git keine Option. Die ursprüngliche Konfiguration des Git-Repositorys, die zu Beginn der Entwicklung festgelegt wurde, lässt sich im Nachhinein nicht mehr ändern. Auch ein Aufteilen von Repositorys ist nicht möglich. Manche Unternehmen behelfen sich daher damit, anstelle eines einzigen großen, viele separate, kleine Repositorys zu nutzen.

Die Problematik eines solchen "Repository-Wuchers" ist jedoch offensichtlich: Projekte, die aus hunderten von einzelnen Git-Repositorys bestehen, sind sehr schwierig zu verwalten, eine vollständige Gesamtsicht auf das Projekt geht verloren. Das wird vor allem bei der Fehlersuche zum Problem: Denn treten beispielsweise im Rahmen einer neuen Softwareversion unerwartet Fehler auf, lassen sich die als Ursache infrage kommenden Änderungen nicht automatisiert über Repository-Grenzen hinweg zurückverfolgen.

Sicherheit geht vor

Die Frage, wer wann und warum welche Änderung im System durchgeführt hat, spielt vor allem in Zeiten, in denen ein sicherer Betrieb von Geräten und Maschinen mehr und mehr von der Fehlerfreiheit der jeweiligen Software abhängt, eine zentrale Rolle - denken wir nur einmal an das selbstfahrende Auto. Auch in komplexen Szenarien mit weltweit verteilten Teams und Entwicklungspartnern müssen Unternehmen daher die Integrität ihrer Software jederzeit sicherstellen und nicht autorisierte Manipulationen von vornherein unterbinden. Dazu sind Authentifizierungen und Berechtigungen unerlässlich - eine Anforderung, die sich mit Git jedoch nicht umsetzen lässt.
Erhält ein Anwender in Git-Zugriff auf ein bestimmtes Repository, ist er automatisch in der Lage, auf alle darin enthaltenen Entwicklungsdaten zuzugreifen, diese einzusehen oder zu welchen Zwecken auch immer zu modifizieren. Unterschiedliche Berechtigungsstufen, beispielsweise im Bezug auf einzelne Projektteile oder Dateien, unterstützt Git nicht.

Dabei dürfen Unternehmen auch nicht aus den Augen verlieren, dass moderne Softwareprojekte aus weit mehr als nur Quellcode bestehen. Auch Grafiken und Sounds, CAD-Pläne, Build-Skripte, Umgebungsartefakte oder begleitende Materialien wie Dokumentationen sind für den fehlerfreien Betrieb einer Software entscheidend. Und diese müssen entsprechend geschützt, versioniert und gesammelt an einem zentralen Ort aufbewahrt werden. Auch hier stellt Git seine Anwender vor Herausforderungen, denn die Lösung ist ausschließlich auf die Verwaltung textbasierter Entwicklungsdateien ausgelegt.
Andere Dateiarten wie Binärdateien lassen sich mit Git nicht versionieren. Hinzu kommt, dass gerade große Binärdateien wie Grafiken die Repository-Größe schnell erhöhen und damit ein effizientes Arbeiten in der Entwicklungsumgebung erschweren bis unmöglich machen. Daher gehen auch hier viele Unternehmen dazu über, große Binärdateien in ein eigenes Repository auszulagern - und verstärken damit die Problematik des Repository-Wuchers noch weiter.

Beschränkungen aufheben - per Hand oder mit Software

Rein technisch ist es durchaus möglich, einige dieser Einschränkungen auf die ein oder andere Weise aufzuheben. So lassen sich getrennte Repositorys beispielsweise manuell wieder zusammenzuflicken, doch dies ist in der Regel mit einem hohen Maß an zusätzlichem Aufwand verbunden. So beschäftigen Unternehmen, die Git im größeren Stil einsetzen, oft eigene IT-Teams, die sich ausschließlich darum kümmern, separate Git-Repositorys zu verknüpfen und eine effiziente Arbeit am Gesamtprojekt von Hand sicherzustellen. Die ursprünglich geringe Investitionshürde für Git wird damit durch die Investitionen die notwendig sind, um die Lösung in komplexen Einsatzszenarien praktikabel zu machen, wieder aufgehoben .

Alternativ sind am Markt zahlreiche sogenannte "Git-Management-Tools" verfügbar, die darauf spezialisiert sind, die Beschränkungen von Git zu einem gewissen Grad zu überwinden. Hierzu integrieren sie die Dateien aus Git in ein zentralisiertes System, das Anwendern zusätzliche Funktionen zur Verwaltung ihres Git-Projekts bietet.
Beispielsweise erhalten Entwickler damit die Flexibilität, ein Projekt nachträglich in kleinere Teile zu unterteilen, oder Funktionen, die einen effizienten Umgang mit unterschiedlichen Dateitypen oder großen Binärdateien ermöglichen. Auch fehlende Sicherheitsaspekte lassen sich so hinzufügen. Beispiele hierfür sind Zugangsbeschränkung bezogen auf IP-Adressen, einzelne Anwender oder Nutzergruppen auf Ebene des Repositorys, Branches, Verzeichnisse oder einzelner Dateien.

In jedem Fall will eine Git-Nutzung in großen Entwicklungsprojekten sorgfältig überlegt sein. Um die negativen Auswirkungen hinsichtlich Kosten, Sicherheit, Geschwindigkeit und Flexibilität so gering wie möglich zu halten, können sich Anwender die Expertise von Systemhäusern und Beratungsunternehmen zunutze machen.