If it's not in git, it does not exist
May. 19, 202520 years ago, there was no git. It’s been quite the coming of age! What started as an obscure tool for Linux maintainers is now trusted for everything “software related”.
Why is that? Well, there is more to git than the “pull, add, commit, push” incantations we got used to. git is more than a CLI for your laptop. It’s a protocol, a server, an architecture and above this, it’s an ecosystem.
TL;DR
Git has impacted each and every position in the software industry, from frontend to HR through project management. A full ecosystem of inter-connected platforms has emerged thanks to its winning features: fast merging, scalability, space efficiency.
The more git-driven is your organization, the more control you have at all steps.
No one really knows the intricacies of git CLI. As a quick test, take the table below and count how many commands you used this year? Maybe not even the ones in bold, let alone the low-level. Not all of them, right?
So if it’s not for the dauting DX, and if git CLI is so complex we have git-flight-rules for it, there must be something else to explain git planetary expansion. Yes, there is. Let’s quickly mention the top 3 architecture choices that triggered its success.
Foundations of Git
Git has collaboration embedded
Back in 2013, when we moved from SVN to Git, what struck me is the unlimited authors per git repository, unlimited git repos per author, and also the free instant branching out. That alone sold it to the dev teams. After a couple of hours in training, we saw number of commits and branches sky-rocket.
Git does not lose data
Because it’s distributed by design, every instance of a git repository contains the full history and content. It does not depend on an external server like previous CVSes. And if you lose your laptop, any other existing copy is a full backup (minus your latest local changes).
Git does not forget
It’s really hard to lose history, unless you do it on purpose. Quick tip, remember the YANAJ rule: “You Are Not A Jedi (YANAJ)”. In other words, only Luke should use the --force, not corworkers. And with a proper commented logs of commits, you can go back in time and understand why this patch, or who did the hot-fix and when that specific release happened.
That said, thanks to these primitives and an outstanding storage model, git has outgrown the CVS landscape to build a full ecosystem around it. After practicing it for years, I’ve came to identify the one pattern pushing this ecosystem bigger.
Git‑driven loop — the unexpected hidden gem of git
To be clear, the git-driven loop was not a design goal when git first came out. But community saw something else than just CVS for Linux and slowly refined this new class of processes on top of git primitives. So here is how the magic happens, in five simple steps.
1.Edit & commit
Start by a new branch, and change config, policy or code and push it to the remote.
2. Review changes
After this, open a PR; this event triggers humans plus linters (or agents!) to validate the proposed changes.
3. Merge
When and if PR is approved, the changes land on the main (or env‑specific) branch.
4. Change propagation
To propagate changes, it can happen in two ways, depending if this git repo is a real “source of truth”, or rather a “source of events”.
4.1 Source of truth triggers a declarative reconciliation
An operator like Argo CD/Flux watches the repo, detects drift and converges live state to match git declared state.
4.2 Source of events trigger a process third-party
A CI pipeline, backup job or webhook runs a one‑shot task (build, test, snapshot) without storing desired state. The changes here are more imperative than declarative, but should still retain idempotency.
5. Report feedback
A critical step for the original author is to ask controller or job to post back a status, or inject metrics, or write comments back on the original PR.
Bonus: Rollback the changes
Need to undo? git revert (or checkout to a previous tag) and the same automation repeats, restoring the prior state. Here is the UML sequence version of the git-driven loop.
Once you understand the git-driven loop, you can apply it to “everything as code”. Indeed, with many years of project management, I came to see a number of tools leveraging the “git-driven” loop. So here is a personal selection of how to leverage “everything as code” and super charge your workflow, from dev to production and more.
Git for software engineers
Since it’s obvious, let’s start with the usual suspects, but with a twist.
Reproducible development environments
For the last few years, coding environments can be defined as code, and I am not talking about spinning up your app with docker compose, even if it’s a great start. If you’re using the awesome vs code (and vscodium), you can drop “devcontainer.json” in a repo and get the exact extensions and settings from a laptop to another. Unified DX (developer experience) through devices and team members. No more “not the same IDE on my laptop”. -> devcontainers official docs
Pipelines for Dev and Ops
Does it build or does it break? You should not commit without running tests (pre-commit hooks, right?). Even though, pipelines has your back, and works to safe guard production from bugs. But not only bug!. Pipelines have now evolved further, for instance bringing CI/CD to infrastructure. That’s what Digger does for Terraform/OpenTofu code. This nifty tool has some bonus features over Atlantis, which I really liked from another startup. Digger can report if infra will be impacted by your changes before you apply them live.
And if YAML is too boring or limited, what about pipelines as code? Yes, Dagger can do that, letting you build most custom pipelines using conditions, loops and whatsnot using your favorite language from one the many Dagger SDKs.
Test everything all the time
What’s the best place to write tests? Near the code, of course. Maybe not inside the code, although I heard D-lang has a built-in feature for that. Next question would be: what kind of tests? As per current trends of web development, everything goes: from unit tests to REST APIs and even headless browsers.
What about pen-tests? or secret scanning? You name it. There is a whole slew of pluggable testing products. They listen to events like git push or merges. After cloning the code at this exact version, the testing framework will work in the background. After a while, the team gets feedback in the git repository itself, as a comment in the PR for instance.
Git for frontend
Can frontend developers collaborate on top of git? Actually Storybook open source platform is a great showcase of how to leverage git during UI development, and even automating frontend tests.
Another special mention to Penpot, a figma open source alternative, where designers create wireframes and then exports are plain SVG/JSON that can be version-controlled and branched like other code. Penpot is self-hostable using Docker.
Git for operations
Git for deployments, aka classic GitOps
GitOps is the discipline of deploying software using a git repository as the source of truth. A simple but powerful idea. For simple projects, it usually goes like this:
- each branch is an environment (production, staging, feature branch, hotfix branch, etc.)
- each commit in a branch triggers a pipeline (build, test, push)
- a new release is materialized by a merge from a branch to production, i.e promote release candidate.
Which means that rollbacks are as easy as a git revert!
The landscape in this field is too crowded for this post. While ArgoCD tends to be the de-facto standard these days, any process that can receive a webhook notification from github/gitlab does qualify as gitops-ready actually. Meaning Docker Swarm is gitops ready, as well as nomad, as well as coolify on your VPS!
Git for Secret management
First of all, never push secrets in a git repository. Now, the only exception is when you deal with sealed secrets. Take a tool like “blackbox”, written and used by folks at Stackoverflow. It’s essentially a wrapper around GPG, and it does a good job at keeping secrets encrypted and stored in git, until you need them, typically during deployment. Since it’s in git, you can version secrets and rotate them in coordination with code releases in pure GitOps fashion. There’s actually a line of similar tools: Kubeseal for K8S, infisical, git-crypt, etc.
Not to be confused with secret-scanning tools like git-secrets or gitleaks, which are also great because they will prevent secrets from being committed. (recommended in a pre-commit hook)
Git for networking
In cloud native era, network traffic can be treated as code. In a micro‑services world you can write Kubernetes NetworkPolicies (or service‑mesh routing objects) in YAML, store them in Git, and have a controller or CI job validate and apply them on merge. This brings pull‑request reviews, history, and instant rollbacks to your firewall. Mandatory mention to the venerable Cilium, which couples eBPF‑powered networking with Git‑driven manifests.
Git for Authentication
Even identity can live in a git repository. With an OSS IdP like authentik, every client, group and policy lives in YAML Blueprints. Commit those files, open a PR, and have CI/ArgoCD apply them on merge—so SSO tweaks enjoy the same reviews, history and “git revert” rollbacks as your app code.
Git for Authorization
If authentication proves identity, authorization decides permissions, and that logic can be version‑controlled too. With OPA Gatekeeper you write Kubernetes admission and RBAC rules in Rego, keep them in Git, and let ArgoCD/Flux sync them on merge. PRs become policy reviews, policy drift disappears, and a bad rule is one git revert away. For teams app‑level ACLs, OpenFGA stores schemas and relationship tuples as code, letting CI test and migrate permissions just like a database. For more details on how to manage RBAC as code for Github, Gdrive or Slack, take a look at the OpenFGA sample stores.
Git for project management
Git for documentation
For anyone with a software product (or God forbid, a public API), up-to-date documentation is actually part of the product. So when you get a new release out, the updated documentation is also part of the release, via its own git “tag”. In this case, a lot of platforms have now frontend text editors using a git repo as content storage, like this blog ;)
With tools like gitbook or as versatile as netlifycms Decap CMS, each contributor can patch documentation, review it and push a new version in coordination with the release manager.
Git for tickets and bug tracking
In case you did not notice, a lot of important data is left out “git clone”. You get all the history, i.e what has been done, but you don’t get what needs to be done. For this, you must go back to tickets which are usually online (github issues or jira tickets). That’s exactly what “git-issue” and “git-bug” are solving. These tools make sure the roadmap stays local to the git repository, and you can update them and track progress as easily as code. Both offer bi-directional integration with GitHub and GitLab issue management, so everyone is free to use CLI or browser.
Git for Backups
Thanks to git remotes, backups management of git repositories is quite trivial. A number of cool tools are coating the “remotes” primitive with a nice UX and automation, like gitbackup for instance or commercial-based Rewind, free for teams < 10 users. Then you can schedule backups in git repositories and keep your intellectual property safe forever.
Git for Data storage
Who said git repositories are for code only? What about using them for to store live data and application state? For instance, Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a Git repository, while staying MySQL compliant. Another less extreme example is OctoDNS that will keep DNS records in git repository so each commit triggers a propagation of updates. In this case, git is used as source of truth, like GitOps but for data.
Git for HR (sic)
The wildest example maybe is the case of git-based onboarding and offboarding your true only. In this past startup, new hires would get all permissions to the many workplace tools as easily as this sequence:
- HR fills a form with employee profile
- Form generates a commit in the team repository
- Pull request runs CI/CD and sends notification to reviewers
- Reviewers approves PR
- Merged commit triggers account creation, and sets IAM roles and policies for new users.
And same for… offboarding. If you have the SSO in place, all it takes is a pipeline to automate HR.
bonus: git for… git
For hardcore git practitioners, there is even pre-commit. It can configure git hooks for a git repo given a hook definition. Ok this is extreme, and technically not git-based, but it’s fun to see how far developers will go to get the perfect coding environment. Love it.
git future is “gitless”
At any point of your journey in IT, there is a git repo to leverage and help you, and when convinced enough you can settle for the hardest git-driven rule:
One last thing, as a we live in times of Agentic AI and Chat as the new UX, git will shine through this trend, using same primitives we learned to love. We saw it in a number of nocode offers like Next-generation tools will definitely include a “gitless” experience (like our HR onboarding example). Think agents using git commits for memory, or versioned tools for their MCP Servers suite.
Git for LLM development
Tools like MLFlow and DVC are working to bring git experience to models development. “It’s designed to make ML models shareable, experiments reproducible, and to track versions of models, data, and pipelines. DVC works on top of Git repositories and cloud storage” (Wikipedia) Quoting DVC docs:
How cool would it be to track large datasets and machine learning models alongside your code
💫 DVC is your “Git for data”!
So the future of git is less about the CLI, and more about building an ecosystem around developers to solve their challenges. The journey is safer with git!
About the author
I am a DevOps veteran, helping Dev and Ops making sense of the Cloud by applying DevOps principles to their processes and tooling. (let’s talk)
My last book “from Dockerfail to Dockerfile” heavily builds on git, please check it out if you are in Platform engineering, DevSecOps or Cloud Native deployments.
All mentioned projects
Here is a reference table for your convenience with all open source projects mentioned in the blog post.
| Tool | Domain | What lives in Git |
|---|---|---|
| Argo CD | K8s deploys | Manifests / Helm charts |
| Flux | K8s deploys | Kustomize / Helm |
| Sealed‑Secrets (Kubeseal) | Secret delivery | SealedSecret (encrypted YAML) |
| Cilium NetworkPolicies | Networking | K8s NetworkPolicy YAML |
| OPA Gatekeeper | Admission / RBAC policy | Rego constraints & templates |
| authentik Blueprints | Identity / IdP | YAML blueprints |
| OctoDNS | DNS | Zone YAML / JSON |
| Terraform + Atlantis | Cloud infra | .tf modules |
| Digger | IaC pipelines | .tf code |
| Dagger | General pipelines | Pipeline code (Go/TS/Py) |
| pre‑commit | Dev UX / lint | .pre‑commit‑config.yaml |
| gitleaks / git‑secrets | Secret scanning | Scanner config |
| Storybook | UI tests | Component stories |
| DVC | ML data/models | .dvc metafiles |
| MLflow | ML experiments | Run metadata & Git SHA |
| Dolt | SQL database | Tables & schema |
| OpenFGA | Fine‑grained authZ | Model & tuple files |
| blackbox / git‑crypt | Encrypted secrets | Ciphertext files |
| git‑issue / git‑bug | Issue tracking | Issues stored as Git objects |
| devcontainers | Dev env | devcontainer.json & Dockerfile |
| Penpot | UI design | SVG / JSON exports |
| Decap CMS | Docs/content | Markdown / MDX |
