WTF is Git, why do I care, and how come it makes me nervous?

Let me tell you something that took me a while to admit: I have been in software for 25 years, and Git made me nervous for longer than it should have. Not confused — I understood the concept fine. Nervous. That specific anxiety of touching something that feels like it has invisible tripwires and a blast radius.

If you manage developers, work alongside them, or are returning to technical work after years on the leadership side — this feeling is extremely common and almost nobody talks about it, because admitting it feels like admitting you don't belong. You do belong. Git is just badly explained, universally, by people who learned it so long ago they've forgotten what it felt like to not understand it.

So let's fix that.

Part 01 — What Git actually is

Git is a version control system — which is a fancy way of saying it's software that tracks every change ever made to a set of files, lets multiple people work on those files at the same time without destroying each other's work, and lets you roll back to any previous state if something goes catastrophically wrong.

That's it. That's the whole thing. Everything else is implementation detail.

The analogy that actually works

Imagine you're writing a very important Word document. You start making a copy every time you finish a big section — proposal_v1.docx, proposal_v2.docx, proposal_FINAL.docx, proposal_FINAL_for_real.docx, proposal_FINAL_USE_THIS_ONE.docx. You've been doing version control. You've just been doing it badly, manually, and with increasingly unhinged filenames. Git automates this — but instead of copies of whole files, it stores just the differences between versions, and it does it for every file in your project simultaneously.

The key insight that changes everything: Git doesn't save files. Git saves snapshots of your project at moments in time. Each snapshot is called a commit. You decide when to take a snapshot, you write a short note about what changed, and Git stores it forever. You can always go back.

Part 02 — Why you should care

If you're working with AI tools like Claude Code, GitHub Copilot, or any agentic coding assistant — Git stops being optional. Every one of these tools assumes you're working inside a Git repository. The good ones will tell you to commit before they start doing anything drastic. The less good ones will just do drastic things and leave you without a safety net.

More practically: if you're building anything with AI assistance, you will at some point end up with code that worked yesterday and doesn't work today and you cannot for the life of you remember what changed. Git is the answer to that problem. Git is always the answer to that problem.

The other reason to care: GitHub. GitHub is where Git lives in the cloud — it's where code is stored, shared, reviewed, and deployed. It's the professional lingua franca of software development. If you're collaborating with a developer, reviewing their work, or just trying to understand what your engineering team is talking about when they mention "the repo" — you're talking about a Git repository on GitHub.

"The single best thing you can do before letting an AI agent touch your code is make a commit. It takes 30 seconds and gives you a time machine."

Part 03 — Why it makes you nervous (and why that's rational)

Git's interface is famously terrible. This is not a controversial opinion — it's a running joke in the industry. The commands are cryptic, the error messages are written for people who already understand what went wrong, and some operations feel genuinely destructive even when they aren't.

Here are the specific fears, named and defused:

"I'll accidentally delete something important"

Git almost never permanently deletes anything. The whole point of Git is that it keeps everything. Even when you think you've lost something, it's usually still there — just in a slightly annoying place to retrieve it from.

The actual risk is low. The perceived risk is high because the commands sound destructive.

"I'll break the main branch and everyone will know"

This is what branches are for. You don't work directly on the main branch. You create a branch — a parallel copy — do your work there, and only merge it back when everything's good. Breaking your own branch affects nobody.

Branches are free, instant, and exist specifically so you can experiment without consequences.

"I don't understand what 'merge conflicts' are and they sound terrible"

A merge conflict happens when two people changed the same line of the same file and Git doesn't know which version to keep. It stops and asks you to decide. It's annoying, not catastrophic — Git marks the conflicting sections clearly and waits for a human to resolve it.

Merge conflicts are Git asking for your judgment. They are solved, not feared.

"The terminology is impenetrable"

Commit, push, pull, clone, branch, merge, rebase, stash, HEAD, origin, upstream. Yes. It's a lot. The good news is you only need about six of these to do 90% of what you'll ever actually do.

See the cheat sheet below. Seriously, that's most of it.

The 90% — Commands you'll actually use

You do not need to memorize Git. You need to recognize these six things and roughly know what they do. The rest you can look up, or ask Claude.

Command What it does in plain English

git init Turns the current folder into a Git repository. You do this once at the start of a project.

git status Shows you what's changed since your last snapshot. Run this constantly. It tells you where you are.

git add . Stages all your changes — tells Git "these are the things I want to include in my next snapshot."

git commit -m "note" Takes the snapshot. The note is for future-you. "Fixed login bug" beats "changes" every single time.

git push Sends your commits up to GitHub. This is your backup. Do this often.

git pull Grabs the latest changes from GitHub. Run this before you start working if other people are on the project.

Part 04 — Git and AI tools — why this matters now

Here's the reason I'm writing this in 2026 and not 2016: AI coding assistants have made Git more important, not less. When Claude Code or any agentic tool is writing and modifying files on your behalf, you need a way to see exactly what changed, revert a bad decision, and checkpoint your progress before each risky move.

My personal workflow — and I'd recommend something like it to anyone:

# See what state we're in
git status

# Snapshot everything as it stands
git add .
git commit -m "checkpoint before AI session"

# Now let the AI do its thing.
# If it goes sideways, you have a clean restore point.

This takes 20 seconds. I have used this restore point more times than I care to admit. Once because Claude confidently refactored something in a direction I didn't ask for. Once because I told it to "clean up the folder" and didn't specify what I meant by that. Once purely out of paranoia that turned out to be justified.

Git doesn't make you a developer. It makes you someone who can work safely alongside tools that move fast and break things. At this moment in time, that's pretty much everyone.

The one thing to take away

If you walk away from this with one habit, make it this: commit before you do anything you're unsure about. Before running a script. Before letting an AI agent loose. Before that "quick refactor" that somehow always gets complicated. Commit first. The 30 seconds you spend now is the undo button you'll be grateful for later.

Next up: Windows Sucks, Buy a Mac — or go Linux if you're cheap and blue collar like me.