Why I Use Git as a Litmus Test When I Judge a Team

Want to know quickly whether a dev team is serious? Look at how it uses Git. Not the tool itself — the branching strategy, the commit messages, the code reviews, who touches what and when. It's the most honest signal of discipline I know: where it exists, the software holds up; where it's missing, I almost always find chaos, bugs and security holes. I've used it as a litmus test for years, and in 2026 it still holds.

TL;DR

Git isn't a backup. It's how a team collaborates without stepping on each other.
A clear branching strategy and readable commits separate manageable projects from unmanageable ones.
That's why it exists: Linus Torvalds built it in 2005 to coordinate thousands of people on the Linux kernel.
Honest note: even my own public repos aren't perfect. Discipline is a practice, not a pose.

Why I use it as a litmus test

When I assess a team or a company, I don't start with the code. I start with how it's tracked. If, in an interview or a due diligence, I find Git used only as "right-click → upload everything", I already have half the answer. Not because it's some snobbish technical detail, but because how you version your work tells me how you think about work: whether you care about being able to go back, about understanding who changed what, about not breaking what works while you build the new piece.

It sounds incredible, but in 2026 — just like in 2014 — there are still companies completely foreign to the idea of working as an organized team: no workflow, no branching, no reviews. Then those same companies complain that their projects go badly, that they're disorganized, full of bugs and — almost always — security holes. It's not bad luck. It's the direct consequence of working without a shared system for collaborating.

Where Git actually comes from

It's worth remembering, because it explains everything. Git wasn't born in a university lecture hall: Linus Torvalds wrote it in 2005, under pressure, because he had to manage the chaos of thousands of people contributing to the Linux kernel at the same time without trampling each other. He needed an efficient, traceable way to collaborate without conflicts — literally to deal with his colleagues as little as possible and let the system mediate concurrent work.

The almost absurd part is that a tool built by one person to organize his own mess became the infrastructure that the first true mass open-source community runs on. Open source needed exactly this: a way to make scattered teams, strangers to one another, collaborate without a boss coordinating by hand. Git is the answer to that need. That's why, when I see it used badly, I feel the very reason it exists is being thrown away.

What happens where discipline is missing

Without versioning discipline	With a clear branching strategy
"Who broke production?" → a mystery	Every change has an author and a reason
Rolling back = panic	Rollback in one command
Changes overwriting each other	Tracked merges, conflicts resolved in plain sight
Security: secrets and bugs slip in unseen	Review before merge, a trail of everything
Onboarding: "trust me, that's how it works"	The repo history is the documentation

I'm not saying Git makes a team good. I'm saying its absence makes it almost impossible to be good beyond a certain scale. It's the floor, not the ceiling.

Honest note: even my repos aren't perfect

I'd be a hypocrite not to admit it. If you look at some of my public repositories, you'll see messy commits, lazy messages, histories I don't tell with pride — and that's already before the arrival of AI. Versioning discipline is hard precisely because it's a continuous practice, not a switch. You slip under pressure, exactly when you'd need it most.

That's why I don't preach it as a dogma from someone who has arrived. I preach it as someone who fights with it every day and knows what it costs to go without. And that's also where the next chapter begins: what happens when speed — and AI — push you to drop this very discipline. I did it recently, and I tell the story here.

FAQ

Is Git useful even if I work alone?

Yes, very. Even solo it lets you go back without fear, experiment on a branch and throw it away, understand what you changed between a version that works and one that broke. The "collaborator" you don't want conflicts with, when you're alone, is you from three weeks ago.

Do small teams need a complicated branching strategy?

No. For most small teams a simple flow is enough: one main branch always working, short-lived branches for each change, review before merge. Complexity gets added only as the team grows. Better a simple process that's respected than an elaborate one that's ignored.

Is using Git badly worse than not using it?

Almost never, but the risk is real: a repo with a misleading history or abandoned branches gives false confidence. The fix isn't to drop it, it's to give yourself three minimum rules and keep them: a branch per task, readable commits, no merge without review.

If you're building or reorganizing a technical team and want to bring order to workflow, architecture and process, let's talk or see what I do as a Fractional CTO. And when you're done here, read the flip side: I dropped Git for speed, and AI let me get away with it.

The Git logo is by Jason Long, licensed under CC BY 3.0.