Letztes Jahr war ich bei einem Maschinenbauer in der Nähe von Stuttgart. 120 Mitarbeitende, eine eigene Softwareentwicklungsabteilung mit sieben Leuten, die seit elf Jahren ein ERP-Modul in C# pflegen. Auf meine Frage, wie sie Versionskontrolle machen, zeigte mir der Entwicklungsleiter einen Netzlaufwerk-Ordner namens Backup_neu_v3_FINAL_2. Git hatten sie offiziell seit zwei Jahren — aber nur einer der Entwickler benutzte es konsequent. Der Rest speicherte „zur Sicherheit" noch immer die .zip-Datei auf dem Server.
Das ist kein Einzelfall. Das ist Mittelstand.
Was Nick Chapsas schreibt — und er schreibt es gut
Nick Chapsas liefert in seinem Artikel einen soliden Einstieg in Git aus .NET-Entwickler-Sicht. Er erklärt die Entstehungsgeschichte (Linus Torvalds, Linux-Kernel, 2005), die Kernkonzepte wie den gerichteten azyklischen Graphen (DAG), und gibt einen praxisnahen Überblick über die wichtigsten Befehle: git init, git clone, git pull, git push, Branching, Merging, Rebasing. Die IDE-Integration in Visual Studio und Rider kommt nicht zu kurz. Alles korrekt, alles verständlich erklärt — Chapsas ist Experte, und man merkt es.
Was fehlt: der Artikel setzt voraus, dass das Team bereits weiß, warum es Git braucht, wie man sich auf einen Workflow einigt, und wer im Zweifelsfall den main-Branch schützt. Das sind drei Annahmen, die im Enterprise-Umfeld gerechtfertigt sind. Im KMU sind sie es nicht.
Wie das in einem Betrieb mit 30 bis 300 Mitarbeitenden wirklich landet
Die Technik ist nicht das Problem. Git zu installieren dauert fünf Minuten. Das Konzept „Commit = Snapshot" versteht jeder Entwickler nach einer halben Stunde. Die Befehle aus Chapsas' Liste — die meisten davon lernt man in einem Nachmittag.
Das Problem ist das Drumherum.
In Unternehmen dieser Größe habe ich folgende Muster immer wieder gesehen:
1. Kein definierter Branching-Workflow. Der Artikel zeigt, wie man einen Branch erstellt und ihn mergt. Er zeigt nicht, wann man das tut. Macht ihr Feature-Branches? Git Flow? Trunk-Based Development? Ohne eine explizite Entscheidung — schriftlich, verpflichtend — arbeitet jeder Entwickler anders. Nach sechs Monaten habt ihr einen main-Branch voller direkter Commits, fünf verwaiste Feature-Branches aus dem letzten Quartal, und niemand weiß mehr, was deployed ist.
Meine Empfehlung für Teams unter zehn Entwicklern: Trunk-Based Development mit kurzlebigen Feature-Branches, maximal zwei Tage Laufzeit, Squash-Merge auf main. Kein Git Flow. Git Flow ist für Teams ab ca. 20 Entwicklern sinnvoll. Darunter ist es Overhead, der regelmäßig zusammenbricht.
2. Keine Branch-Protection-Rules. Visual Studio macht es einfach, direkt auf main zu pushen. Und in kleinen Teams passiert das — meistens kurz vor Feierabend, meistens von der Person, die „ja nur kurz was fixen" wollte. Auf GitHub, GitLab und Azure DevOps kannst du erzwingen, dass ein Pull Request mindestens eine Approval braucht, bevor etwas auf main landet. Das ist kein bürokratischer Aufwand, das ist Qualitätssicherung für Betriebe, die keine dedizierte QA-Abteilung haben. Aktivierungsaufwand: 10 Minuten. Ertrag: signifikant weniger „Wer hat das eingecheckt?"-Meetings.
3. Commit-Messages als Datenmüll. Der Artikel empfiehlt, eine beschreibende Commit-Message zu schreiben. Er erklärt nicht, warum das im KMU-Kontext wirtschaftlich ist. Ich sage es dir konkret: Wenn ein Steuerberater eurer Eigenentwicklung eine neue Funktion braucht und ihr in drei Monaten rausfinden müsst, welche Version auf dem Produktivsystem läuft und was sich wann geändert hat — dann sind 47 Commit-Messages mit dem Text „fix" ungefähr so hilfreich wie gar keine. Ein einfaches Format wie [Ticket-123] Beschreibung was und warum kostet 30 Sekunden pro Commit und spart bei der nächsten Betriebsprüfung oder beim nächsten Rollback Stunden.
4. Git ≠ Backup. Das ist der gefährlichste Irrtum, den ich im Mittelstand sehe. Teams, die Git einführen, hören manchmal auf, anderweitig zu sichern — weil „das Repo ja auf GitHub liegt." Ein Remote-Repository ist kein Backup-System. Backups sind versionierte, getrennt gespeicherte, regelmäßig auf Wiederherstellbarkeit getestete Kopien. Wenn ihr euer Repo auf einem selbst gehosteten GitLab habt und der Server brennt, ist das Repo weg. Punkt.
Was ich konkret empfehle
Wenn du ein Team von drei bis fünfzehn Entwicklern führst oder bist und gerade Git einführst oder konsolidierst:
-
Entscheidet euch für einen Workflow und schreibt ihn auf. Eine halbe DIN-A4-Seite reicht. Was landet wann auf main? Wer darf mergen? Wie heißen Branches?
-
Aktiviert Branch-Protection auf main. Sofort. Kostet nichts, schützt alles.
-
Definiert ein Commit-Message-Format. Ticket-Nummer + Freitext, fertig. Macht es zur Pflicht, nicht zur Empfehlung.
-
Hosted euer Repo bei einem Managed-Anbieter (GitHub, Azure DevOps, GitLab SaaS), nicht selbst — außer ihr habt explizite Compliance-Gründe dagegen. Der Wartungsaufwand für einen selbst gehosteten Git-Server übersteigt den Nutzen für Teams dieser Größe regelmäßig.
-
Macht ein einmaliges 2-Stunden-Team-Training mit echten Szenarien: Merge-Konflikt lösen, versehentlichen Commit rückgängig machen, einen Release-Tag setzen. Nicht mit Slides — mit dem echten Repo.
Nick Chapsas' Artikel ist der richtige erste Schritt. Die technische Grundlage stimmt. Aber zwischen „ich verstehe git push" und „unser Team arbeitet stabil mit Git" liegt meistens ein Organisations-Problem, kein Technik-Problem.
Der vollständige Original-Beitrag von Nick Chapsas: Git for .NET Developers
Wenn du gerade mitten in der Git-Einführung steckst oder dein Team seit zwei Jahren Git „benutzt" und es trotzdem immer wieder knirscht — ich schaue mir das gerne einmal konkret mit dir an.
— Bernhard