Versionsverwaltung

02Wie das funktioniert

Der gesamte Code einer Anwendung liegt mitsamt seiner Historie in einem Repository. Jeder Entwickler arbeitet mit einer Kopie davon, und die Kopie auf der Plattform ist der gemeinsame Stand.

Vier Begriffe decken das meiste ab, was im Alltag passiert:

• Commit: ein gespeicherter Schritt. Er bündelt Änderungen an einer oder mehreren Dateien mit einer Nachricht wie „Fälligkeitsdatum auf Rechnungen anzeigen“. Jeder Commit hat eine eindeutige Kennung und lässt sich einzeln ansehen, vergleichen oder rückgängig machen.
• Branch: ein eigener Arbeitsstrang. Ein Entwickler legt für eine Aufgabe einen Branch an, speichert dort seine Commits und lässt den Hauptstrang unberührt, bis die Aufgabe fertig ist.
• Pull Request: der Vorschlag, die Arbeit aus einem Branch in den Hauptstrang zu übernehmen. Er zeigt jede geänderte Zeile, rot für entfernt und grün für hinzugefügt, zusammen mit einer Beschreibung, was die Änderung tut und warum.
• Merge: die Übernahme des Pull Requests. Die Commits aus dem Branch werden Teil des Hauptstrangs, und die Historie hält fest, wer sie freigegeben hat.

03Prüfung vor der Übernahme

Im Pull Request wird die Qualität geprüft. Jemand anderes als der Autor liest die Änderung, stellt Fragen, verlangt Korrekturen und gibt sie schließlich frei. Auf den meisten Plattformen lässt sich der Hauptstrang schützen, sodass nichts ohne Freigabe und ohne bestandene automatische Tests hineinkommt.

An dieser Stelle kann auch die Geschäftsführung die Arbeit verfolgen, ohne Code zu lesen. Jeder Pull Request hat einen Titel und eine Beschreibung in normaler Sprache, einen Verweis auf die zugehörige Aufgabe und das Ergebnis der Tests. Die Liste der übernommenen Pull Requests ist eine Liste aller Änderungen an der Anwendung, in der richtigen Reihenfolge.

04Ein Beispiel aus einer Geschäftsanwendung

Angenommen, ein Unternehmen schreibt seine Rechnungen mit einer Webanwendung, und die Buchhaltung meldet, dass Gutschriften seit letztem Dienstag den falschen Umsatzsteuersatz zeigen.

Mit einer Versionsverwaltung sieht sich der Entwickler die Historie der Datei an, die die Umsatzsteuer berechnet, und findet einen Pull Request, der sie am Montag geändert hat. Laut Beschreibung kam damit eine neue Rabattart hinzu. Der Entwickler liest die betroffenen Zeilen, findet den Fehler, schreibt die Korrektur auf einem neuen Branch und öffnet einen Pull Request, der auf den verursachenden verweist. Eine Kollegin prüft ihn, die Tests laufen, und die Korrektur ist noch am selben Tag übernommen.

Hätte die Korrektur länger gedauert, hätte der Entwickler die fehlerhafte Änderung auch allein zurücknehmen können. Git legt dann einen neuen Commit an, der genau diese Zeilen rückgängig macht, und alle anderen Änderungen seitdem bleiben erhalten.

05Alternativen

Vor Git waren zentrale Systeme wie Subversion (SVN) verbreitet. Sie halten die Historie auf einem Server, und Entwickler müssen für die meisten Schritte damit verbunden sein. Manche älteren Unternehmen nutzen sie noch. Git hält die vollständige Historie in jeder Kopie, ist dadurch schneller und erlaubt Arbeit ohne Verbindung.

Unter den Plattformen ist GitHub die größte. GitLab bietet ähnliche Funktionen und lässt sich auch auf eigenen Servern betreiben. Bitbucket gehört zu Atlassian und wird oft von Teams gewählt, die schon Jira nutzen. Alle drei arbeiten mit Git, ein Repository kann also samt Historie von einer zur anderen umziehen.

Arbeit ganz ohne Versionsverwaltung, mit Code in Ordnern, auf dem Laptop eines einzelnen Entwicklers oder als ZIP-Datei verschickt, kommt in kleinen Projekten noch vor. Dann gibt es keine verlässliche Aufzeichnung, was sich geändert hat, und keinen sauberen Weg zurück, wenn etwas kaputtgeht.

06Worauf Sie beim Einkauf achten sollten

Wenn jemand Software für Sie baut, ist das Repository das Wertvollste, was er übergibt. Diese Fragen lohnen sich vor Projektbeginn:

• In wessen Konto liegt das Repository? Am besten in einer Organisation auf GitHub oder GitLab, die Ihrem Unternehmen gehört, mit den Entwicklern als eingeladenen Mitgliedern.
• Bekommen Sie den vollständigen Code, mit Skripten und Konfiguration, und die Dokumentation, die man zum Betrieb braucht?
• Läuft jede Änderung über einen Pull Request mit Prüfung, oder schreiben Entwickler direkt in den Hauptstrang?
• Sind die automatischen Tests an die Pull Requests gekoppelt, sodass eine Änderung mit fehlschlagenden Tests nicht übernommen werden kann?
• Bleiben Passwörter und Zugangsschlüssel aus dem Repository heraus? Sie gehören in die Einstellungen des Hosting-Anbieters.

07Wie wir sie nutzen

Unser gesamter Code liegt auf GitHub. Jede Änderung, ob von einem von uns oder von einem unserer KI-Agenten geschrieben, läuft über einen Pull Request. Der Agent, der eine Änderung schreibt, gibt sie nie selbst frei: Andere Agenten prüfen sie auf Fehler, auf die Qualität der Daten und auf Sicherheit, die automatischen Tests laufen, und einer von uns beiden gibt sie frei, bevor sie übernommen wird.

Änderungen an Anmeldung, Berechtigungen oder Passwörtern bekommen zusätzlich eine eigene Sicherheitsprüfung. Jeder Pull Request beschreibt in normaler Sprache, was er tut, und so ist die Historie zugleich ein Protokoll jeder Entscheidung.

Bei der Übergabe bekommt der Kunde den Code in sein eigenes GitHub-Konto und kann mit uns, mit einem anderen Team oder allein weitermachen.

Häufige Fragen