TrenchOps DE 🇩🇪🐎 
Sie müssen kein "Git-Nerd" sein
Und genau das ertragen die echten Git-Nerds nicht
Ich habe einmal zugesehen, wie ein Senior-Entwickler 45 Minuten damit verbrachte, einer Berufsanfängerin interaktives Rebasing zu erklären. Sie wollte nur einen Tippfehler in einer Commit-Nachricht rückgängig machen.
Um etwa Minute acht wurde ihr Blick glasig. Um Minute zwanzig stellte sie im Kopf ihre Einkaufsliste zusammen. Um Minute vierzig zweifelte sie an ihrer Berufswahl. Der Senior-Entwickler bemerkte nichts davon. Er hatte den Spaß seines Lebens.
Das ist die Git-Community in einem einzigen Bild.
Jetzt mein Geständnis: Ich kenne vielleicht fünf Git-Befehle. Clone, add, commit, push, pull. An einem verrückten Tag vielleicht noch ein checkout. Das war's. Das ist der komplette Werkzeugkasten. Er funktioniert. Er hat immer funktioniert. Und noch nie ist etwas in Flammen aufgegangen, weil ich den gerichteten azyklischen Graphen hinter meiner Versionshistorie nicht durchschaut habe.
"Aber weißt du überhaupt, was ein DAG ist?"
Ja. Ich weiß, was ein DAG ist. Ich weiß auch, was ein Vergaser ist. Trotzdem baue ich meinen Motor nicht selbst zusammen. Für alle, die es nicht wissen: "Git DAG bezeichnet die Datenstruktur des gerichteten azyklischen Graphen, die als architektonisches Rückgrat von Git dient und die Commit-Historie des Repositorys abbildet."
Die Git-Enthusiasten - und das sage ich mit ehrlicher Zuneigung für ihre Leidenschaft - haben einen ganz speziellen blinden Fleck. Sie können sich schlicht nicht vorstellen, dass ein fähiger Programmierer sich für Git jenseits des Grundnutzens einfach nicht interessiert. Für sie ist das, als würde sich ein Koch nicht für Messer interessieren. Für uns übrige ist es eher, als würde sich ein Koch nicht für Metallurgie interessieren.
Git ist ein Versionskontrollsystem. Es löst das Problem "Ich muss zurück zu dem Zeitpunkt, als das noch funktionierte". Das ist alles. Das ist die Aufgabe. Und für diese Aufgabe reichen fünf Befehle vollkommen aus.
Aber jetzt wird es interessant. Denn die Git-Besessenheit verrät etwas Tieferes über die ganze Branche.
Warum brauchen wir überhaupt ein derart komplexes Werkzeug für Versionskontrolle? Warum brauchen achtköpfige Teams ausgefeilte Branching-Strategien, Workflows zur Auflösung von Merge-Konflikten und ganze Bücher - echte, veröffentlichte Bücher mit ISBN - über die Verwaltung ihrer Quellcode-Historie?
Weil die Sprachen und Architekturen, mit denen sie arbeiten, es nötig machen.
Denken Sie kurz darüber nach. Wenn zwölf Leute an derselben 3.000-Zeilen-Datei herumschrauben, brauchen Sie ausgefeiltes Merge-Werkzeug. Wenn Ihre Sprache alles in monolithische Strukturen mit enger Kopplung zwängt, brauchen Sie Branching-Strategien, damit sich niemand gegenseitig auf die Füße tritt. Wenn Ihr Deployment ein zerbrechliches Ritual ist, das kippt, sobald jemand Zeile 847 ändert, während ein anderer an Zeile 212 werkelt, dann brauchen Sie den kompletten Git-Apparat.
Aber das ist kein Git-Problem. Das ist ein Design-Problem. Ein Sprach-Problem. Ein Architektur-Problem.
Gut entworfene, modulare Systeme mit sauberer Trennung der Zuständigkeiten? Da spielt Versionskontrolle kaum eine Rolle. Sie lösen keine Konflikte auf, weil es keine gibt. Ihre Module sind unabhängig. Ihre Schnittstellen sind stabil. Ihre Änderungen sind isoliert.
Git ist brillante Ingenieurskunst. Linus Torvalds hat es gebaut, um den Linux-Kernel zu verwalten - eines der komplexesten kollaborativen Softwareprojekte der Menschheitsgeschichte, mit Tausenden von Mitwirkenden an Millionen von Codezeilen. Für diesen Fall ist jede einzelne Funktion gerechtfertigt.
Die CRUD-App Ihres Teams mit sieben Microservices? Sie parken damit rückwärts ein - mit dem Telemetriesystem eines Formel-1-Wagens.
Die Softwarebranche pflegt eine lange Tradition: Sie baut immer raffiniertere Umgehungslösungen für Probleme, die es gar nicht geben sollte. Datenbank-ORMs, die schlechtes Schema-Design übertünchen. Containerisierung, die das "Bei mir läuft's doch"-Chaos beim Deployment kaschiert. Ausufernde CI/CD-Pipelines, die nur existieren, weil niemand dem Build-Prozess traut. Und ja - komplexe Git-Workflows, die für Sprachen und Architekturen geradestehen, die Zusammenarbeit von Natur aus gefährlich machen.
Das ist das Muster: Statt die Ursache zu beheben, bauen wir ein Werkzeug. Dann bauen wir eine Community um das Werkzeug. Dann wird das Werkzeug zur Identität. Und dann ist jeder verdächtig, der diese Identität nicht teilt.
"Du nutzt kein Git Flow? Wie kommst du überhaupt..."
"Du hast noch nie interaktiv rebased? Das ist... bedenklich."
"Du solltest wirklich mal Pro Git lesen. Sind nur 500 Seiten."
Nein.
Und jetzt kommt die Pointe, die die Git-Jünger wirklich schmerzt:
Das erledigen inzwischen KI-Agenten.
Ich erinnere mich beim besten Willen nicht mehr an den letzten Git-Befehl, den ich von Hand getippt habe. Die Agenten machen das einfach. Sie committen, sie branchen, sie pushen, sie lösen auf. Wenn ich etwas Ungewöhnliches brauche, beschreibe ich auf Deutsch (bzw. Englisch), was ich will, und die Maschine tüftelt aus, welche Kombination aus Gits über 150 Befehlen das erledigt.
Genau so sieht das richtige Verhältnis zu einem Werkzeug aus. Sie sagen ihm, was Sie brauchen. Es tut das Ding. Sie machen mit Ihrer eigentlichen Arbeit weiter.
Ich höre den Einwand schon: "Aber was, wenn etwas schiefgeht und Sie verstehen müssen, was passiert ist?"
In über zwanzig Jahren musste ich vielleicht dreimal die Git-Interna verstehen, um mich aus einem Desaster zu retten. Und jedes Mal war die schnellste Lösung, jemanden zu fragen, der ein "Git-Nerd" ist. Der brauchte vier Minuten. Ich brauchte null Stunden Lektüre über das Reflog.
Es gibt hier ein Konzept, das Charlie Munger gefallen würde: die Opportunitätskosten von Expertise. Jede Stunde, in der Sie zum Git-Zauberer werden, ist eine Stunde, in der Sie Ihre Kunden nicht besser verstanden, Ihre Architektur nicht verbessert, kein Konzept gelernt haben, das Sie wirklich unterscheidbar macht. Git-Wissen hat für sich genommen fast keinen Marktwert. Niemand stellt "den Git-Menschen" ein. Aber Menschen stellen sehr wohl denjenigen ein, der sauberen, modularen, gut getesteten Code liefert - völlig egal, ob er den Drei-Wege-Merge-Algorithmus erklären kann.
Das eigentliche Thema hat gar nichts mit Git zu tun. Es geht um den Unterschied zwischen Werkzeugbeherrschung und Handwerksbeherrschung.
Werkzeugbeherrschung heißt, jede Option jedes Befehls zu kennen. Handwerksbeherrschung heißt, zu wissen, welche Probleme man lösen muss, und seine Arbeit so zu strukturieren, dass die Werkzeuge kaum noch ins Gewicht fallen. Die besten Tischler zeichnen sich nicht durch ihr Verhältnis zum Maßband aus.
Ich habe dieses Muster in jedem Werkzeug-Ökosystem wiederkehren sehen. Die Vim-gegen-Emacs-Fraktion. Die Kubernetes-Enthusiasten. Die Terraform-Jünger. Es gibt immer eine Gruppe, die sich in das Werkzeug selbst verliebt statt in das Ergebnis, das es hervorbringt. Und sie betrachten die Leute, die das Werkzeug einfach nur benutzen, ausnahmslos als schlichte Zivilisten, die es eben nicht "kapiert" haben.
Wir kapieren es. Es ist uns nur egal. Und das ist in Ordnung. Mehr als das - es ist womöglich die produktivere Haltung.
👉 Git ist ein gelöstes Problem. Fünf Befehle decken 98 % des Alltags ab. Investieren Sie Ihr Lernbudget woanders.
👉 Komplexe Git-Workflows kaschieren oft architektonisches Versagen. Wenn Ihr Team ein Branching-Strategie-Dokument braucht, das länger als eine Seite ist, liegt das Problem nicht bei der Versionskontrolle.
👉 Werkzeug-Identität ist keine berufliche Identität. "Der Git-Mensch" zu sein ist, als wäre man "der Tacker-Mensch". Gelegentlich nützlich, aber keine Karriere.
👉 KI-Agenten haben diese ganze Debatte erledigt. Die Werkzeuge bedienen jetzt die Werkzeuge. Ihre Aufgabe ist zu wissen, was zu bauen ist - nicht, wie man es committet.
Die beste Versionskontroll-Strategie ist, Code zu schreiben, der keine aufwendige Versionskontrolle braucht.
👇 Welches Werkzeug überschätzt Ihr Team - gemessen am tatsächlichen Nutzen, den es liefert?
0 comment(s)
No comments yet. Be the first to comment.
Leave a comment