Legacy-Software ohne Git: Warum Versionskontrolle fehlt und was das bedeutet

Legacy software kein git: Das ist kein Sonderfall. Es ist die Regel. Viele Projekte, die heute noch produktiv laufen, wurden zu einer Zeit gebaut, als Versionskontrolle kein Standard war. Änderungen landeten direkt per FTP auf dem Server. Sicherheitskopien hießen index_backup_20090415.php. Und niemand hat das später nachgeholt.

Was das für die Wartung und Sicherheit solcher Systeme bedeutet und wie man schrittweise Ordnung einführt, erklärt dieser Artikel.

Was ist Versionskontrolle und warum fehlt sie bei alten Projekten?

Versionskontrolle ist ein System, das jede Änderung am Code aufzeichnet. Git (gesprochen: "git") ist das heute am weitesten verbreitete Werkzeug dafür. Es wurde 2005 veröffentlicht. Viele Systeme, die heute noch produktiv laufen, entstanden davor oder kurz danach.

Damals war es üblich, Dateien direkt auf den Server zu laden. Änderungen wurden nicht protokolliert. Wer Sicherheit wollte, legte eine Kopie an. Diese Praxis war keine Nachlässigkeit. Sie war der Standard.

Das Problem entsteht, wenn diese Systeme weiter betrieben werden, ohne dass jemand nachträglich Struktur einführt. Versionskontrolle ist kein Luxus. Sie ist das Gedächtnis des Projekts.

Was konkret fehlt, wenn kein Git vorhanden ist

Fehlende Versionskontrolle hat direkte Folgen. Es sind keine abstrakten Risiken, sondern Probleme die spätestens dann sichtbar werden, wenn jemand eine Änderung machen muss.

Keine Nachvollziehbarkeit

Wer hat wann was geändert? Bei Legacy Software ohne Git gibt es darauf oft keine Antwort. Dateien wurden überschrieben. Kommentare fehlen. Was gestern noch funktionierte, funktioniert heute nicht mehr. Und niemand weiß warum.

Das macht selbst kleine Eingriffe riskant. Man weiß nicht, was man anfasst.

Kein sicheres Rollback

Wenn eine Änderung einen Fehler auslöst, muss man zurückkönnen. Mit Git dauert das Sekunden. Ohne Git greift man auf Backups zurück, wenn welche vorhanden sind. Oft sind sie veraltet. Manchmal fehlen sie ganz.

Das bedeutet: Ein einziger Fehler kann den laufenden Betrieb zum Stillstand bringen.

Kein paralleles Arbeiten

Sobald mehr als eine Person am Projekt arbeitet, entstehen Konflikte. Person 1 überschreibt die Datei, bevor Person 2 ihre Änderungen hochladen kann. Das klingt nach einem kleinen Problem. In der Praxis kostet es Stunden und hinterlässt fehlerhaften Code.

Keine Transparenz für externe Entwickler

Wer ein fremdes System übernimmt, braucht Kontext. Was hat sich in den letzten Jahren verändert? Welche Entscheidungen wurden getroffen? Bei technischen Schulden, die sich über Jahre angesammelt haben, ist diese Frage besonders wichtig.

Ohne Git gibt es keine Antworten. Nur Dateien, deren Geschichte niemand kennt.

Warum das bei Legacy-Projekten besonders kritisch ist

Bei aktiv entwickelten Projekten fällt fehlende Versionskontrolle schnell auf. Das Team stößt auf Probleme und handelt.

Bei Legacy-Projekten, die selten angefasst werden, bleibt das Problem im Verborgenen. Bis jemand eine Änderung machen muss.

Das können verschiedene Anlässe sein: ein Sicherheits-Update, eine neue gesetzliche Anforderung, eine technische Störung. In diesem Moment zeigt sich, wie fragil ein System ohne Git ist.

Niemand weiß, was der aktuelle Stand des Codes ist. Der Code auf dem Server weicht vom Backup ab. Das Backup weicht von dem ab, was der letzte Entwickler lokal gespeichert hatte. Und niemand weiß, welche Version die "echte" ist.

Das ist keine Theorie. Das ist ein Szenario, das wir bei der Übernahme älterer Projekte regelmäßig antreffen. Ein System ohne Versionskontrolle ist ein System ohne Gedächtnis.

Wie man nachträglich Git einführt

Die gute Nachricht: Es ist möglich, auch für bestehende Projekte Versionskontrolle einzuführen. Es braucht keinen Komplettumbau. Es braucht einen klaren ersten Schritt.

Schritt 1: Den tatsächlichen Ist-Stand sichern

Bevor irgendetwas geändert wird, muss der aktuelle Stand des Systems festgehalten werden. Nicht das lokale Backup. Nicht den letzten Stand den der Entwickler kannte. Den tatsächlichen Code, der auf dem Server läuft.

Das ist wichtig. Oft weicht der Server-Stand von allem anderen ab, ohne dass jemand es bemerkt hat.

Schritt 2: Git-Repository anlegen

Ein Git-Repository ist die Heimat des Codes. Es kann lokal liegen oder auf einer Plattform wie GitHub oder GitLab, beide sind weit verbreitet und erprobt. Den gesicherten Code ins Repository laden. Den Stand als ersten Commit erfassen. Ab diesem Punkt gibt es eine Versionshistorie.

Schritt 3: Regeln für künftige Änderungen festlegen

Jede Änderung am Code wird ab jetzt per Commit erfasst. Jeder Commit bekommt eine kurze Beschreibung. Das kostet wenige Minuten und spart in Zukunft viele Stunden.

Wichtig: Nicht auf den perfekten Zeitpunkt warten. Mit einem unvollkommenen Repository anfangen ist besser als mit keinem.

Schritt 4: Deployment-Prozess anpassen

Dieser Schritt ist optional, aber empfehlenswert: Das Deployment direkt aus dem Git-Repository steuern. Statt Dateien per FTP hochzuladen, wird immer der aktuelle Stand aus dem Repository genutzt. So driften Server und Repository nicht wieder auseinander.

Was Git nicht löst

Git ist kein Allheilmittel. Es macht fehlende Tests nicht wett. Es ersetzt keine Dokumentation. Und es ändert nichts an veralteten PHP-Versionen oder anderen technischen Risiken.

Aber es schafft eine Grundlage. Wer weiß, was sein Code tut und wann es sich wie verändert hat, kann sinnvoll planen. Ohne diese Grundlage arbeitet man im Dunkeln.

Wann braucht man externe Hilfe?

Nicht jedes Team kann diese Schritte allein gehen. Das ist keine Kritik. Es ist eine ehrliche Einschätzung der Situation.

Wenn die Person, die das System kennt, kein Entwickler ist, oder wenn das System besonders komplex aufgebaut ist, lohnt es sich, Unterstützung zu holen. Die Einführung von Git in ein bestehendes Projekt ist kein großes Vorhaben. Es setzt aber Erfahrung mit Legacy-Code voraus.

Wir übernehmen diese Aufgabe regelmäßig im Rahmen der Software-Wartung. Den Ist-Stand erfassen, Git einrichten, den Deployment-Prozess stabilisieren. Schritt für Schritt, ohne den laufenden Betrieb zu stören.

Fazit: Legacy software kein git ist lösbar

Wer ein System ohne Versionskontrolle betreibt, hat eine Anwendung, die niemand vollständig versteht. Kein Entwickler. Kein Administrator. Oft nicht einmal derjenige, der es ursprünglich gebaut hat.

Das Risiko zeigt sich spätestens dann, wenn jemand eine Änderung machen muss und nicht weiß, wo er anfangen soll.

Die Lösung ist kein Großprojekt. Sie ist ein erster Commit.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen, was der sinnvolle nächste Schritt ist.