Git, of: De discipline die blijft

Ik herinner me een avond, lang voordat Git mijn werk bepaalde.

Een configuratiemap. Tientallen bestanden, elk met een achtervoegsel dat moest verraden wanneer het voor het laatst was aangeraakt: sysctl.conf.bak, sysctl.conf.old, sysctl.conf.2021, sysctl.conf.final, sysctl.conf.ECHT_final. Niemand wist nog welke versie gold. Niemand wist wie wat wanneer had gewijzigd. En de vraag waarom een bepaalde regel stond waar hij stond — die beantwoordde hoogstens een commentaar dat iemand ooit had achtergelaten. Meestal antwoordde niemand.

Dat was geen uitzondering. Dat was de norm.

En toen kwam een hulpmiddel dat niet voor ons bedoeld was — en onze wereld toch blijvend veranderde.

Een hulpmiddel dat niet voor ons bedoeld was

Git ontstond in 2005, gebouwd door Linus Torvalds om het kernelproject te beheren. Het was gemaakt voor programmeurs: broncode, patches, gedistribueerde samenwerking aan grote codebasis. Administratoren kwamen er niet in voor.

In het begin klonken de termen vreemd. Commits, branches, merge, rebase, remote, push, pull, head, detached head. Taal die bij compilers hoorde, niet bij de machinekamer. Wie sysadmin was, had iets anders te doen.

Maar sommigen van ons probeerden het uit. Plaatten /etc onder versiebeheer. Volgden hun dotfiles — de kleine configuratiebestanden in de thuismap, het persoonlijke handschrift van elke beheerder. En plotseling merkten we: dit hulpmiddel paste beter bij ons werk dan het ooit voor ons bedoeld was.

Wat Git anders maakt

In de kern slaat Git momentopnames op, geen verschillen. Elke commit is een volledig beeld van de staat op één tijdstip — ophaalbaar, vergelijkbaar, herstelbaar. Elke wijziging is cryptografisch beveiligd, via hashwaarden. Manipulatie wordt zichtbaar. Geschiedenis wordt onveranderlijk — zolang je haar niet met opzet herschrijft.

Dat klinkt technisch. In waarheid is het een belofte: Niets gaat verloren. Alles is na te trekken.

Wie ooit een configuratie stuk heeft bewerkt en niet meer wist hoe hij eerder zag, begrijpt wat deze belofte waard is. git diff toont wat er veranderde. git log -p toont de hele geschiedenis, regel voor regel. git blame noemt de auteur van elke afzonderlijke regel — en de commit die hem toevoegde. git revert maakt een wijziging ongedaan zonder de geschiedenis te wissen.

Voor Git was een reparatie een gokspel. Met Git is het een vraag.

Transparantie en omkeerbaarheid

Twee eigenschappen hebben systeembeheer blijvend veranderd: transparantie en omkeerbaarheid.

Transparantie betekent: elke wijziging heeft een auteur, een tijdstip en een rechtvaardiging — het commitbericht. Wie iets wil weten, vindt het. Niet in een wiki die niemand onderhoudt. Niet in het hoofd van een collega die net op vakantie is. Maar direct in de geschiedenis die het systeem zelf bijhoudt.

Omkeerbaarheid betekent: elke staat die ooit bestond kan worden hersteld. Een defecte update, een kapotte configuratie, een per ongeluk verwijderd blok — allemaal terug te halen. Dat neemt de schrik uit experimenteren. Wie weet dat hij kan terugkeren, waagt meer.

Deze twee eigenschappen samen veranderen hoe je werkt. Je waagt meer, omdat het risico kleiner is. Je documenteert nauwkeuriger, omdat de commits toch blijven staan. Je denkt in staten, niet in acties.

Discipline die je niet afschudt

Hier wordt het ongemakkelijk. En precies hier ligt de eigenlijke waarde.

Git beloont niet wie snel is. Git beloont wie schoon werkt. Het dwingt tot atomaire commits — kleine, in zichzelf consistente wijzigingen in plaats van monsterpatches. Het dwingt tot zinvolle commitberichten — omdat een bericht genaamd „stuff" over zes maanden niemand helpt. Het dwingt tot branches als je iets riskants probeert — in plaats van stiekem op de hoofdvertakking te knoeien.

Ja, dat is vervelend. Ja, samenvoegconflicten irriteren. Ja, een detached head kan een beginner in paniek brengen. Ja, een mislukte rebase voelt alsof je de controle bent kwijtgeraakt — tot je leert dat git reflog elke stap weer klaar houdt.

Maar dat is geen bug. Dat is het lesprogramma.

Wie met Git werkt, leert precisie. Leert wijzigingen te isoleren. Leert gedachten te formuleren voordat ze worden vastgelegd. Leert dat consistentie geen staat is die bij toeval ontstaat, maar een gewoonte die je oefent.

Is dat niet wat we eisen? Consistentie. Precies dat geeft Git ons. En meer.

Van ontwikkelaarstool naar fundament

Kijken we naar de periode tussen 2010 en nu. Wat veranderde is niet alleen het gebruik van Git. Het is de positie van Git.

Rond 2010 was versiebeheer voor veel beheerders optioneel. Sommigen gebruikten SVN, sommigen RCS, velen helemaal niets. Configuraties leefden op de servers waar ze werkten. Back-up maken betekende kopiëren.

Vandaag, in 2026, is Git de lucht die infrastructuur ademt. /etc onder Git is allang standaardpraktijk — hulpmiddelen zoals etckeeper automatiseren het. Dotfiles leven in repositories, gesynchroniseerd over meerdere machines. En de hele beweging van infrastructuur als code — Ansible, Terraform, OpenTofu, Puppet, Kubernetes-manifesten — rust op Git. Zonder Git zou zij in deze vorm niet bestaan.

Daaruit is iets nieuws ontstaan: GitOps. Het idee dat Git de enige bron van waarheid is. Flux, ArgoCD en vergelijkbare hulpmiddelen bewaken een repository en vereffenen de werkelijkheid automatisch — elke merge is een uitrol, elke commit een auditvermelding. Wijzigingsbeheer gebeurt onderweg, als onderdeel van het gewone werkproces. In plaats van zware goedkeuringsprocessen dienen pull requests als lichtgewicht controlemiddel.

Dat is geen trend. Dat is een nieuwe basisaanname.

Ook alleen

Misschien denk je: dat geldt alleen voor teams. Klopt niet.

Wie volledig alleen werkt — een solo-beheerder, een freelancer, iemand die zijn homelab onderhoudt — profiteert net zo. Misschien zelfs meer.

Zes maanden nadat je een sysctl-regel hebt gezet, vraag je je af waarom. Zonder Git raad je. Met Git typ je git log -p sysctl.conf en lees je je eigen redenering — in het commitbericht dat je toen schreef. Jouw vroegere ik legt de beslissing uit aan jouw huidige ik.

Dotfiles in een Git-repository betekenen: een nieuwe machine staat in minuten. Een schijfcrash is geen drama, maar een clone. Jouw persoonlijke werkplaats is overal waar jij bent.

En de discipline werkt ook zonder collega’s die meelezen. Wetend dat je commits blijven staan — ook al kijkt niemand mee — werk je schoner. Niet uit angst, maar uit gewoonte. Git maakt consistentie tot routine, ongeacht of er een team naast je staat of niet.

De ongemakkelijke kant, eerlijk gezegd

Git is niet vriendelijk. De syntaxis is inconsistent. Sommige operaties zijn gevaarlijk zonder dat meteen zichtbaar. De documentatie is omvangrijk maar niet altijd uitnodigend. Wie ooit een force-push naar de verkeerde branch loosde, vergeet het nooit meer.

Maar vriendelijkheid was nooit het doel. Juistheid was het doel. En juistheid duldt geen gemakzucht.

De strengheid van Git is geen gebrek. Zij is de voorwaarde voor wat het presteert. Een hulpmiddel dat elke fout vergeeft, leert geen zorgvuldigheid. Een hulpmiddel dat fouten zichtbaar maakt en waarvan het ongedaan maken soms pijnlijk is, leert aandacht. De pijn is de les.

Consistentie is wat Git ons geeft

Uiteindelijk gaat het niet om snelheid. Niet om functierijkdom. Niet om populariteit.

Het gaat om consistentie.

Git maakt consistentie niet optioneel. Het maakt het de voorwaarde opdat überhaupt iets werkt. Het neemt ons de mogelijkheid af om halfslachtig te werken — en geeft ons daarvoor iets belangrijkers terug: vertrouwen in onze eigen staat. Wie weet wat op zijn systemen is geconfigureerd, omdat het in de historie staat, slaapt rustiger. Wie weet dat hij kan terugkeren, waagt meer. Wie weet dat elke wijziging moet worden gerechtvaardigd, denkt helderder.

Dat is wat systeembeheer tegenwoordig betekent. Niet prutsen, maar bouwen. Niet hopen, maar weten. Geluk niet, maar consistentie.

Wat libcom.de inbrengt

Bij libcom.de werken we vanaf onze beginperiode met Git — niet als experiment, maar als fundament. Onze playbooks, onze configuraties, onze documentatie: alles onder versiebeheer, alles na te trekken, alles onderworpen aan review.

In twee decennia praktijk is meer gegroeid dan ervaring. Er is een cultuur ontstaan — een houding waarin transparantie vanzelfsprekend is en omkeerbaarheid geen concessies doet. We weten hoe bestaande, onbeheerde systemen vatbaar worden gemaakt zonder de bedrijfsvoering te onderbreken. We weten hoe GitOps wordt ingevoerd zonder het team te overrijden. We weten wanneer een pull-request-review echte kwaliteit oplevert en wanneer het lege formalisme is.

Als je infrastructuur nog zonder versiebeheer werkt, hoef je niet bij nul te beginnen. We helpen bestaande staten vast te leggen, naar Git over te hevelen en stap voor stap een praktijk op te bouwen die consistentie tot gewoonte maakt. Als je al beheert, helpen we work flows robuuster te maken, reviews effectiever en drift weg te nemen.

En als je gewoon wilt weten waar je staat: we nemen inventaris op. Eerlijk, na te trekken, zonder verkoopdruk.

De eerste stap is een gesprek. Schrijf ons op contact@libcom.de — schets je situatie, en samen vinden we uit of en hoe we kunnen helpen. Geen verplichting, geen pitch. Alleen een eerlijke uitwisseling over wat je infrastructuur nodig heeft.

Misschien is dat de eigenlijke vooruitgang. Niet dat we een nieuw hulpmiddel hebben gekregen. Maar dat we zijn gestopt op geheugen en geluk te leunen.

Infrastructuur die werkt omdat ze gebouwd is — niet omdat iemand oplette. Dat is de standaard die we nastreven. En dat is de standaard die Git ons mogelijk maakt.