Git, oder: Die Disziplin, die bleibt

Ich erinnere mich an einen Abend, lange bevor Git meine Arbeit bestimmte.

Ein Konfigurationsverzeichnis. Dutzende Dateien, jede mit einem Suffix, das verraten sollte, wann sie zuletzt angefasst wurde: sysctl.conf.bak, sysctl.conf.old, sysctl.conf.2021, sysctl.conf.final, sysctl.conf.WIRKLICH_final. Niemand wusste mehr, welche Version galt. Niemand wusste, wer was wann geändert hatte. Und die Frage, warum eine bestimmte Zeile stand, wo sie stand — die beantwortete bestenfalls ein Kommentar, den irgendjemand irgendwann hinterlassen hatte. Meistens antwortete niemand.

Das war kein Einzelfall. Das war die Norm.

Und dann kam ein Werkzeug, das nicht für uns gedacht war — und unsere Welt dennoch dauerhaft veränderte.

Ein Werkzeug, das nicht für uns gedacht war

Git entstand 2005, gebaut von Linus Torvalds, um das Kernel-Projekt zu verwalten. Es war gemacht für Programmierende: für Quellcode, für Patches, für verteilte Zusammenarbeit an großen Codebasen. Administratoren kamen darin nicht vor.

Anfangs klangen die Begriffe fremd. Commits, Branches, Merge, Rebase, Remote, Push, Pull, Head, Detached Head. Eine Sprache, die zur Compilerschaft gehörte, nicht zum Maschinenraum. Wer Sysadmin war, hatte anderes zu tun.

Aber einige von uns probierten es aus. Legten /etc unter Versionskontrolle. Trackten ihre Dotfiles — die kleinen Konfigurationsdateien im Heimatverzeichnis, die persönliche Handschrift jedes Administrators. Und plötzlich merkten wir: Dieses Werkzeug passt besser zu unserer Arbeit, als es je für uns gedacht war.

Was Git anders macht

Im Kern speichert Git Snapshots, keine Differenzen. Jeder Commit ist ein vollständiges Bild des Zustands zu einem Zeitpunkt — abrufbar, vergleichbar, wiederherstellbar. Jede Änderung ist kryptografisch gesichert, über Hashwerte. Manipulation wird erkennbar. Geschichte wird unveränderlich — solange man sie nicht mit Absicht umschreibt.

Das klingt technisch. Es ist in Wahrheit ein Versprechen: Nichts geht verloren. Alles ist nachvollziehbar.

Wer jemals eine Konfiguration kaputteditiert hat und nicht mehr wusste, wie sie vorher aussah, versteht, was dieses Versprechen wert ist. git diff zeigt, was sich geändert hat. git log -p zeigt die gesamte Geschichte, Zeile für Zeile. git blame nennt den Autor jeder einzelnen Zeile — und den Commit, der sie hinzugefügt hat. git revert macht eine Änderung rückgängig, ohne die Historie zu löschen.

Vor Git war eine Reparatur ein Glücksspiel. Mit Git ist sie eine Frage.

Transparenz und Reversibilität

Zwei Eigenschaften haben die Systemadministration dauerhaft verändert: Transparenz und Reversibilität.

Transparenz bedeutet: Jede Änderung hat einen Urheber, einen Zeitpunkt und eine Begründung — die Commit-Message. Wer etwas wissen will, findet es. Nicht in einem Wiki, das niemand pflegt. Nicht im Kopf eines Kollegen, der gerade Urlaub hat. Sondern direkt in der Geschichte, die das System selbst führt.

Reversibilität bedeutet: Jeder Zustand, der einmal dagewesen ist, kann wiederhergestellt werden. Ein fehlerhaftes Update, eine kaputte Konfiguration, ein versehentlich gelöschter Block — alles rückholbar. Das nimmt den Schrecken aus dem Experiment. Wer weiß, dass er zurückkehren kann, traut sich weiter.

Diese beiden Eigenschaften zusammen verändern, wie man arbeitet. Man wagt mehr, weil das Risiko kleiner ist. Man dokumentiert genauer, weil die Commits ohnehin erhalten bleiben. Man denkt in Zuständen, nicht in Aktionen.

Disziplin, die man nicht abschütteln kann

Hier wird es unbequem. Und genau hier liegt der eigentliche Wert.

Git belohnt nicht, wer schnell ist. Git belohnt, wer sauber arbeitet. Es zwingt zu atomaren Commits — kleine, in sich schlüssige Änderungen statt Monster-Patches. Es zwingt zu aussagekräftigen Commit-Messages — weil eine Message namens „stuff" in sechs Monaten niemandem hilft. Es zwingt zu Branches, wenn man etwas Riskantes versucht — statt heimlich am Hauptzweig herumzudoktern.

Ja, das ist lästig. Ja, Merge-Konflikte nerven. Ja, ein Detached Head kann einen Anfänger in Panik versetzen. Ja, ein misslungener Rebase fühlt sich an, als hätte man die Kontrolle verloren — bis man lernt, dass git reflog jeden Schritt noch einmal bereithält.

Aber das ist kein Bug. Das ist der Lehrplan.

Wer mit Git arbeitet, lernt Präzision. Lernt, Änderungen zu isolieren. Lernt, Gedanken zu formulieren, bevor man sie committet. Lernt, dass Konsistenz kein Zustand ist, der zufällig entsteht, sondern eine Gewohnheit, die man übt.

Ist das nicht, was wir fordern? Konsistenz. Genau das gibt uns Git. Und mehr.

Vom Entwicklerwerkzeug zum Fundament

Schauen wir auf den Zeitraum zwischen 2010 und heute. Was sich verändert hat, ist nicht nur die Nutzung von Git. Es ist die Stellung von Git.

Um 2010 herum war Versionskontrolle für viele Administratoren optional. Manche nutzten SVN, manche RCS, viele gar nichts. Konfigurationen lebten auf den Servern, auf denen sie funktionierten. Backup bedeutete kopieren.

Heute, 2026, ist Git die Luft, die Infrastruktur atmet. /etc unter Git ist längst Standardpraxis — Werkzeuge wie etckeeper automatisieren es. Dotfiles leben in Repositories, synchronisiert über mehrere Maschinen hinweg. Und die gesamte Bewegung der Infrastruktur als Code — Ansible, Terraform, OpenTofu, Puppet, Kubernetes-Manifeste — ruht auf Git. Ohne Git gäbe es sie nicht in dieser Form.

Daraus ist etwas Neues entstanden: GitOps. Die Idee, dass Git die einzige Quelle der Wahrheit ist. Flux, ArgoCD und ähnliche Werkzeuge überwachen ein Repository und gleichen die Realität automatisch an — jeder Merge ist ein Deployment, jeder Commit ein Audit-Eintrag. Change Management wird nebenbei erledigt, als Teil des normalen Arbeitsflusses. Statt schwerfälliger Genehmigungsprozesse gibt es Pull Requests als leichtgewichtiges Kontrollinstrument.

Das ist kein Trend. Das ist eine neue Grundannahme.

Auch allein

Vielleicht denken Sie: Das gilt nur für Teams. Stimmt nicht.

Wer völlig allein arbeitet — ein Solo-Administrator, ein Freiberufler, jemand, der sein Homelab pflegt — profitiert genauso. Vielleicht sogar mehr.

Sechs Monate nachdem Sie eine sysctl-Zeile gesetzt haben, fragen Sie sich, warum. Ohne Git raten Sie. Mit Git tippen Sie git log -p sysctl.conf und lesen Ihre eigene Begründung — in der Commit-Message, die Sie damals geschrieben haben. Ihr vergangenes Ich erklärt Ihrem jetzigen Ich die Entscheidung.

Dotfiles im Git-Repository bedeuten: Eine neue Maschine ist in Minuten eingerichtet. Ein Festplattenausfall ist kein Drama, sondern ein Clone. Ihre persönliche Werkstatt ist überall, wo Sie sind.

Und die Disziplin wirkt auch ohne Kollegen, die reviewing. Wer weiß, dass seine Commits erhalten bleiben — auch wenn niemand zuschaut — arbeitet sauberer. Nicht aus Angst, sondern aus Gewohnheit. Git macht Konsistenz zur Routine, unabhängig davon, ob ein Team danebensteht oder nicht.

Die unbequeme Seite, ehrlich gesagt

Git ist nicht freundlich. Die Syntax ist inkonsistent. Manche Operationen sind gefährlich, ohne dass es auf den ersten Blick erkennbar wäre. Die Dokumentation ist umfangreich, aber nicht immer einladend. Wer einmal ein Force-Push auf den falschen Branch losgelassen hat, vergisst es nicht.

Aber Freundlichkeit war nie das Ziel. Richtigkeit war das Ziel. Und Richtigkeit verträgt keine Bequemlichkeit.

Die Härte von Git ist kein Makel. Sie ist die Bedingung für das, was es leistet. Ein Werkzeug, das jeden Fehler verzeiht, lehrt keine Sorgfalt. Ein Werkzeug, das Fehler sichtbar macht und deren Rücknahme teilweise schmerzhaft ist, lehrt Aufmerksamkeit. Der Schmerz ist der Unterricht.

Konsistenz ist, was uns Git gibt

Am Ende ist es nicht die Geschwindigkeit. Nicht die Funktionsvielfalt. Nicht die Beliebtheit.

Es ist die Konsistenz.

Git macht Konsistenz nicht optional. Es macht sie zur Voraussetzung, dass überhaupt etwas funktioniert. Es nimmt uns die Möglichkeit, halbherzig zu arbeiten — und gibt uns dafür etwas zurück, das wichtiger ist: Vertrauen in den eigenen Zustand. Wer weiß, was auf seinen Systemen konfiguriert ist, weil es in der History steht, schläft ruhiger. Wer weiß, dass er zurückkehren kann, wagt mehr. Wer weiß, dass jede Änderung begründet sein muss, denkt klarer.

Das ist es, was Systemadministration heute bedeutet. Nicht Basteln, sondern Bauen. Nicht Hoffen, sondern Wissen. Nicht Glück, sondern Konsistenz.

Was libcom.de dazubringt

Wir bei libcom.de arbeiten seit unseren Anfängen mit Git — nicht als Experiment, sondern als Fundament. Unsere Playbooks, unsere Konfigurationen, unsere Dokumentation: alles versioniert, alles nachvollziehbar, allem einem Review unterworfen.

In zwei Jahrzehnten Praxis ist mehr entstanden als Erfahrung. Es ist eine Kultur gewachsen — eine Haltung, in der Transparenz selbstverständlich ist und Reversibilität keine Kompromisse eingeht. Wir wissen, wie man bestehende, unversionierte Systeme erfassbar macht, ohne den Betrieb zu unterbrechen. Wir wissen, wie man GitOps einführt, ohne das Team zu überfahren. Wir wissen, wann ein Pull-Request-Review echte Qualität bringt und wann es leerer Formalismus ist.

Wenn Ihre Infrastruktur noch ohne Versionskontrolle arbeitet, müssen Sie nicht von null beginnen. Wir helfen, bestehende Zustände zu erfassen, in Git zu überführen und schrittweise eine Praxis aufzubauen, die Konsistenz zur Gewohnheit macht. Wenn Sie bereits versionieren, unterstützen wir dabei, Workflows robuster zu machen, Reviews wirkungsvoller zu gestalten und Drift zu beseitigen.

Und wenn Sie einfach wissen möchten, wo Sie stehen: Wir machen Bestandsaufnahme. Ehrlich, nachvollziehbar, ohne Verkaufsdruck.

Der erste Schritt ist ein Gespräch. Schreiben Sie uns an contact@libcom.de — schildern Sie Ihre Situation, und wir finden gemeinsam heraus, ob und wie wir helfen können. Keine Pflicht, kein Pitch. Nur ein ehrlicher Austausch darüber, was Ihre Infrastruktur braucht.

Vielleicht ist das der eigentliche Fortschritt. Nicht, dass wir ein neues Werkzeug bekommen haben. Sondern dass wir aufgehört haben, uns auf Gedächtnis und Glück zu verlassen.

Infrastruktur, die funktioniert, weil sie gebaut ist — nicht weil jemand aufgepasst hat. Das ist der Standard, den wir anstreben. Und das ist der Standard, den Git uns ermöglicht.