You Don't Need to Be "Into Git"

October 20, 2026 SupportTrenches High-Performer Career Strategies 6 minutes

And the people who are really into git can't handle that

I once watched a senior developer spend 45 minutes explaining interactive rebasing to a junior who just wanted to undo a typo in a commit message.

The junior's eyes glazed over around minute eight. By minute twenty, she was mentally composing her grocery list. By minute forty, she was questioning her career choices. The senior developer never noticed. He was having the time of his life.

This is the git community in a nutshell.

Here's my confession: I know maybe five git commands. Clone, add, commit, push, pull. On a wild day, maybe a checkout. That's it. That's the whole toolkit. It works. It has always worked. Nothing has ever caught fire because I didn't understand the directed acyclic graph underlying my version history.

"But do you even know what a DAG is?"

Yes. I know what a DAG is. I also know what a carburetor is. I still don't rebuild my own engine. For those who don't: "Git DAG refers to the Directed Acyclic Graph data structure that serves as the architectural backbone of Git, representing the repository's commit history."

The git enthusiasts - and I say this with genuine affection for their passion - have a specific blindspot. They cannot fathom that a competent programmer might simply not care about git beyond its basic utility. To them, this is like a chef not caring about knives. To the rest of us, it's like a chef not caring about metallurgy.

Git is a version control system. It solves the problem of "I need to go back to when this worked." That's it. That is the job. And for that job, five commands are plenty.

But here's where it gets interesting, and where the git obsession reveals something deeper about the industry.

Why do we need such a complex tool for version control in the first place? Why do teams of eight need elaborate branching strategies and merge conflict resolution workflows and entire books - actual published books with ISBNs - about managing their source code history?

Because the languages and architectures they're working with make it necessary.

Think about it. If you're working in a codebase where twelve people are editing the same 3,000-line file, you need sophisticated merge tooling. If your language forces everything into monolithic structures with tight coupling, you need branching strategies to keep people from stepping on each other. If your deployment is a fragile ceremony that can break because someone changed line 847 while someone else changed line 212, you need the full git apparatus.

But that's not a git problem. That's a design problem. That's a language problem. That's an architecture problem.

Well-designed modular systems with clean separation of concerns? The version control barely matters. You're not merging conflicts because there are no conflicts. Your modules are independent. Your interfaces are stable. Your changes are isolated.

Git is brilliant engineering. Linus Torvalds built it to manage the Linux kernel - one of the most complex collaborative software projects in human history, with thousands of contributors touching millions of lines of code. For that use case, every feature is justified.

Your team's CRUD app with seven microservices? You're using a Formula 1 telemetry system to parallel park.

The software industry has a long tradition of building increasingly sophisticated workarounds for problems that shouldn't exist in the first place. Database ORMs that paper over bad schema design. Containerization that compensates for "works on my machine" deployment chaos. Elaborate CI/CD pipelines that exist because nobody trusts the build process. And yes - complex git workflows that compensate for languages and architectures that make collaboration inherently dangerous.

This is the pattern: instead of fixing the root cause, we build a tool. Then we build a community around the tool. Then the tool becomes identity. Then anyone who doesn't share the identity is suspect.

"You don't use git flow? How do you even..."

"You've never rebased interactively? That's... concerning."

"You should really read Pro Git. It's only 500 pages."

No.

And here's the punchline that really bothers the git devotees:

AI agents handle it now.

I genuinely don't remember the last time I typed a git command manually. The agents just do it. They commit, they branch, they push, they resolve. If I need something unusual, I describe what I want in English and the machine figures out which combination of git's 150+ commands accomplishes it.

This is the correct relationship with a tool. You tell it what you need. It does the thing. You move on with your actual work.

I can already hear the objection: "But what if something goes wrong and you need to understand what happened?"

In twenty-plus years, the number of times I've needed to understand git internals to recover from a disaster: maybe three. And each time, the fastest solution was asking someone who was "into git." Took them four minutes. Took me zero hours of reading about reflog.

There's a concept Charlie Munger would appreciate here. The opportunity cost of expertise. Every hour you spend becoming a git wizard is an hour you didn't spend understanding your customers, improving your architecture, learning a concept that actually differentiates you. Git knowledge has near-zero market value on its own. Nobody hires "the git person." But people absolutely hire the person who ships clean, modular, well-tested code - regardless of whether they can explain the three-way merge algorithm.

The deeper issue isn't about git at all. It's about the difference between tool mastery and craft mastery.

Tool mastery is knowing every option of every command. Craft mastery is knowing which problems to solve and structuring your work so the tools barely matter. The best carpenters aren't defined by their relationship with their tape measure.

I've watched this pattern repeat across every tool ecosystem. Vim versus Emacs people. Kubernetes enthusiasts. Terraform devotees. There's always a cohort that falls in love with the tool itself rather than the outcome the tool produces. And they always, without exception, look at people who just use the tool as simple civilians who don't "get it."

We get it. We just don't care. And that's fine. More than fine - it might actually be the more productive stance.

👉 Git is a solved problem. Five commands cover 98% of daily needs. Invest your learning budget elsewhere.

👉 Complex git workflows often compensate for architectural failures. If your team needs a branching strategy document longer than one page, the problem isn't version control.

👉 Tool identity is not professional identity. Being "the git person" is like being "the stapler person." Useful occasionally, not a career.

👉 AI agents have made this entire debate moot. The tools handle the tools now. Your job is knowing what to build, not how to commit it.

The best version control strategy is writing code that doesn't need elaborate version control.

👇 What tool does your team over-invest in relative to the value it actually delivers?

Software EngineeringAICultureLearningTechnical DebtProductivityGitSoftware Architecture