EXECUTIVE SUMMARY
Versionsverwaltung ist keine Frage des Alters einer Programmiersprache. Gerade gewachsene VB5- und VB6-Projekte profitieren von einer nachvollziehbaren Änderungshistorie. Der Beitrag zeigt, welche Risiken und Abhängigkeiten zuerst sichtbar gemacht werden sollten und wie eine schrittweise Modernisierung kontrollierbar bleibt.
GIT
Git für VB5 - und VB6 - Projekte: Warum sich der Einstieg lohnt
Versionsverwaltung ist keine Frage des Alters der Programmiersprache
Bei modernen Projekten ist Git selbstverständlich. Bei VB5- und VB6-Anwendungen findet man dagegen noch erstaunlich oft Verzeichnisse wie „Projekt_alt“, „Projekt_neu“, „Projekt_final“ oder Sicherungskopien auf Netzlaufwerken. Das kann jahrelang funktionieren – bis nachvollzogen werden muss, welche Änderung wann und warum erfolgt ist.
Gerade bei Legacy-Software ist Versionsverwaltung besonders wertvoll. Denn hier sind Änderungen häufig riskanter, Entwicklerwissen knapper und eine stabile Ausgangsversion wichtiger als bei einem leicht ersetzbaren Neuprojekt.
Erst verstehen. Dann gezielt modernisieren.
Eine belastbare Entscheidung beginnt mit Quellcode, Daten, Abhängigkeiten und dem tatsächlichen Geschäftswert der bestehenden Lösung.
Was Git konkret verbessert
Git schafft zunächst eine eindeutige Historie. Änderungen an Formularen, Modulen, Klassen und Projektdateien können einem Zeitpunkt und einem Bearbeiter zugeordnet werden. Vor einer riskanten Änderung lässt sich ein definierter Stand markieren. Wenn etwas schiefgeht, ist klar, welche Dateien verändert wurden.
Darüber hinaus erleichtert Git die Übergabe. Ein neuer Entwickler erhält nicht irgendeine Kopie des Quellcodes, sondern einen definierten Repository-Stand mit Historie. Das reduziert die Gefahr, dass auf einer veralteten Sicherung weitergearbeitet wird.
VB6 hat einige Besonderheiten
VB6-Projekte bestehen überwiegend aus textbasierten Dateien und lassen sich grundsätzlich gut versionieren. Trotzdem sollte die Einführung kontrolliert erfolgen. Formulare bestehen beispielsweise aus FRM-Dateien und gegebenenfalls zugehörigen FRX-Binärdateien. Beide gehören zusammen. Auch Projektdateien, Klassen, Module und relevante Konfigurationsdateien müssen vollständig erfasst werden.
Nicht in das Repository gehören dagegen beliebige temporäre Dateien, lokale Build-Ausgaben oder Datenbanken mit produktiven Daten. Deshalb sollte vor dem ersten Commit festgelegt werden, was Bestandteil des reproduzierbaren Quellbestands ist und was bewusst ausgeschlossen wird.
Der erste Commit ist eine Bestandsaufnahme
Vor der Einführung sollte nicht einfach das gesamte Entwicklungsverzeichnis in Git geschoben werden. Zuerst wird geprüft: Ist dies wirklich der aktuelle Quellstand? Lässt sich daraus die produktive Anwendung erzeugen? Welche OCX-/DLL-Komponenten werden benötigt? Gibt es externe Dateien oder Skripte?
Erst wenn dieser Ausgangspunkt geklärt ist, entsteht der initiale Commit. Idealerweise wird er mit der aktuell produktiven Programmversion gekennzeichnet. Damit gibt es erstmals einen belastbaren Referenzpunkt.
Branches müssen nicht kompliziert sein
Ein kleines Legacy-Team benötigt kein aufwendiges Git-Modell. Häufig reicht ein stabiler Hauptzweig und für größere Änderungen ein separater Arbeitszweig. Entscheidend ist nicht die Anzahl der Branches, sondern dass Änderungen bewusst, nachvollziehbar und mit einer kurzen Beschreibung eingecheckt werden.
Für produktive Releases sind Tags hilfreich. Ein Tag wie „v3.42-produktiv“ ist wesentlich eindeutiger als ein Ordner „Version_342_neu_final“ auf einem Fileserver.
Was Git nicht löst
Git ersetzt keine Sicherung der Entwicklungsumgebung. Wenn ein Projekt nur mit einer bestimmten VB6-Installation, speziellen Controls oder alten Datenbanktreibern gebaut werden kann, müssen auch diese Voraussetzungen dokumentiert und gesichert werden. Git schützt den Quellbestand – nicht automatisch die gesamte Toolchain.
Ebenso wenig ersetzt Git Tests oder fachliches Wissen. Ein sauber versionierter Fehler bleibt ein Fehler. Der Nutzen entsteht aus der Kombination von Versionsverwaltung, reproduzierbarem Build, Dokumentation und kontrollierten Releases.
Ein pragmatischer Einführungsplan
Schritt eins ist die Sicherung des aktuellen Quellstands. Schritt zwei ist ein Test-Build. Danach werden Repository und Ausschlussregeln eingerichtet, der produktive Ausgangsstand eingecheckt und markiert. Anschließend sollten alle Änderungen nur noch über das Repository erfolgen.
Bei besonders alten Entwicklungsrechnern kann zusätzlich eine virtuelle Maschine sinnvoll sein, in der die komplette Entwicklungsumgebung konserviert wird. Repository und Entwicklungsumgebung erfüllen dabei unterschiedliche Aufgaben und ergänzen sich.
Fazit
Git macht aus VB6 keine moderne Programmiersprache. Es macht aber den Umgang mit einem wertvollen Altbestand deutlich professioneller. Änderungen werden nachvollziehbar, Übergaben einfacher und der aktuelle Quellstand eindeutig.
Gerade wenn eine Anwendung noch mehrere Jahre betrieben oder schrittweise modernisiert werden soll, gehört Versionsverwaltung zu den ersten Maßnahmen – lange bevor über eine komplette Neuentwicklung entschieden werden muss.
NÄCHSTER SCHRITT
Bestehende Software zuerst belastbar einordnen.
Ein unabhängiger Legacy Software Check schafft eine belastbare Grundlage für die nächsten technischen und wirtschaftlichen Entscheidungen.
Unverbindlich sprechen →