I remember an evening, long before Git shaped my work.
A configuration directory. Dozens of files, each with a suffix meant to reveal when it was last touched: sysctl.conf.bak, sysctl.conf.old, sysctl.conf.2021, sysctl.conf.final, sysctl.conf.REALLY_final. Nobody knew anymore which version held. Nobody knew who changed what, or when. And the question of why a particular line sat where it sat — that was answered, at best, by a comment somebody left sometime. Mostly, nobody answered.
That was no isolated case. That was the norm.
And then came a tool that wasn’t meant for us — and reshaped our world for good anyway.
A tool that wasn’t meant for us
Git appeared in 2005, built by Linus Torvalds to manage the kernel project. It was made for programmers: for source code, for patches, for distributed collaboration on large codebases. Administrators did not appear anywhere in it.
At first the terms sounded alien. Commits, branches, merge, rebase, remote, push, pull, head, detached head. A language that belonged to compilers, not to the engine room. Anyone who was a sysadmin had other things to do.
But some of us tried it. Put /etc under version control. Tracked their dotfiles — the small configuration files in the home directory, the personal handwriting of every administrator. And suddenly we noticed: this tool fits our work better than it was ever designed to.
What makes Git different
At its core Git stores snapshots, not differences. Every commit is a complete picture of the state at a point in time — retrievable, comparable, restorable. Every change is cryptographically secured, through hash values. Tampering becomes detectable. History becomes immutable — unless you deliberately rewrite it.
That sounds technical. In truth it is a promise: Nothing is lost. Everything is traceable.
Anyone who has ever edited a configuration to death and no longer knew how it looked before understands what that promise is worth. git diff shows what changed. git log -p shows the entire history, line by line. git blame names the author of every single line — and the commit that added it. git revert undoes a change without deleting the history.
Before Git, a repair was a gamble. With Git, it is a question.
Transparency and reversibility
Two properties have changed system administration for good: transparency and reversibility.
Transparency means: every change has an author, a timestamp, and a justification — the commit message. Anyone who wants to know something finds it. Not in a wiki nobody maintains. Not in the head of a colleague currently on holiday. But directly in the history the system keeps itself.
Reversibility means: any state that once existed can be restored. A faulty update, a broken configuration, an accidentally deleted block — all recoverable. That drains the dread from experimentation. Knowing you can return lets you venture further.
Together these two change how you work. You dare more, because the risk is smaller. You document more precisely, because the commits survive regardless. You think in states, not in actions.
Discipline you cannot shake off
This is where it gets uncomfortable. And this is exactly where the true value lies.
Git does not reward whoever is fast. Git rewards whoever works cleanly. It forces atomic commits — small, self-consistent changes instead of monster patches. It forces meaningful commit messages — because a message called “stuff” helps nobody in six months. It forces branches when you attempt something risky — instead of quietly tinkering on the main trunk.
Yes, that is tedious. Yes, merge conflicts annoy. Yes, a detached head can panic a beginner. Yes, a botched rebase feels as though you’ve lost control — until you learn that git reflog keeps every step ready once more.
But that is not a bug. That is the curriculum.
Whoever works with Git learns precision. Learns to isolate changes. Learns to formulate thoughts before committing them. Learns that consistency is not a state that arises by chance, but a habit you practise.
Isn’t that what we demand? Consistency. That is exactly what Git gives us. And more.
From developer tool to foundation
Look at the stretch between 2010 and today. What changed is not only the use of Git. It is the standing of Git.
Around 2010, version control was optional for many administrators. Some used SVN, some RCS, many nothing at all. Configurations lived on the servers where they worked. Backup meant copying.
Today, 2026, Git is the air infrastructure breathes. /etc under Git is long-standing standard practice — tools like etckeeper automate it. Dotfiles live in repositories, synced across machines. And the entire infrastructure-as-code movement — Ansible, Terraform, OpenTofu, Puppet, Kubernetes manifests — rests on Git. Without Git it would not exist in this form.
Out of that something new arose: GitOps. The idea that Git is the single source of truth. Flux, ArgoCD and similar tools watch a repository and reconcile reality automatically — every merge is a deployment, every commit an audit entry. Change management happens along the way, as part of the ordinary workflow. Instead of cumbersome approval processes, pull requests serve as a lightweight instrument of control.
That is not a trend. That is a new baseline assumption.
Alone, too
Perhaps you think: that applies only to teams. It doesn’t.
Whoever works entirely alone — a solo administrator, a freelancer, someone tending a homelab — benefits just as much. Possibly more.
Six months after you set a sysctl line, you wonder why. Without Git you guess. With Git you type git log -p sysctl.conf and read your own reasoning — in the commit message you wrote back then. Your past self explains the decision to your present self.
Dotfiles in a Git repository mean: a new machine is set up in minutes. A disk failure is not a drama, but a clone. Your personal workshop is wherever you are.
And the discipline bites even without colleagues reviewing. Knowing your commits persist — even when nobody watches — makes you work cleaner. Not out of fear, but out of habit. Git turns consistency into routine, regardless of whether a team stands beside you or not.
The uncomfortable side, honestly told
Git is not friendly. Its syntax is inconsistent. Some operations are dangerous without being visibly so. The documentation is voluminous but not always welcoming. Whoever has loosed a force-push onto the wrong branch does not forget it.
But friendliness was never the goal. Correctness was the goal. And correctness tolerates no complacency.
The harshness of Git is not a flaw. It is the condition for what it achieves. A tool that forgives every mistake teaches no care. A tool that makes mistakes visible and whose undoing is partly painful teaches attentiveness. The pain is the lesson.
Consistency is what Git gives us
In the end it is not speed. Not breadth of features. Not popularity.
It is consistency.
Git does not leave consistency optional. It makes it the precondition for anything to work at all. It removes our ability to work half-heartedly — and gives us back something more important: trust in our own state. Whoever knows what is configured on their systems, because it stands in the history, sleeps more soundly. Whoever knows they can return dares more. Whoever knows every change must be justified thinks more clearly.
That is what system administration means today. Not cobbling, but building. Not hoping, but knowing. Not luck, but consistency.
What libcom.de contributes
At libcom.de we have worked with Git since our beginnings — not as an experiment, but as a foundation. Our playbooks, our configurations, our documentation: all versioned, all traceable, all subject to review.
Over two decades of practice, more than experience has grown. A culture has formed — an attitude in which transparency is taken for granted and reversibility brooks no compromise. We know how to make existing, unversioned systems capturable without interrupting operations. We know how to introduce GitOps without steamrolling the team. We know when a pull-request review delivers genuine quality and when it is empty formalism.
If your infrastructure still works without version control, you do not have to start from zero. We help capture existing states, move them into Git, and gradually build a practice that makes consistency habitual. If you already version, we help make workflows more robust, reviews more effective, and eliminate drift.
And if you simply want to know where you stand: we take inventory. Honestly, traceably, without sales pressure.
The first step is a conversation. Write to us at contact@libcom.de — describe your situation, and together we will find out whether and how we can help. No obligation, no pitch. Just an honest exchange about what your infrastructure needs.
Perhaps that is the real progress. Not that we gained a new tool. But that we stopped relying on memory and luck.
Infrastructure that works because it was built — not because someone was paying attention. That is the standard we aim for. And that is the standard Git lets us reach.