Git and GitHub: why version control matters

Git is the most important tool in modern software, and the one most often explained backwards. Tutorials throw branches, merges, and remote refs at you before you know what git is even for. Let's do it the other way: what problem does git solve, and how does it solve it?

The problem git solves

Imagine you're editing a document, and an hour into the work you realise your last set of changes broke something important. You want to go back — but only to onespecific point, not all the way to last week. And tomorrow you might want to try out a wild idea without it affecting the version you've been sharing with your team. And when you're happy with the wild idea, you want to fold it back in.

Word's undo button can't do that. Manually copying folders called backup-final-v3-actually-final/doesn't scale. What you need is a tool that takes snapshots of your project on demand, lets you compare them, jump between them, branch off, merge back, and shows the entire history.

That tool is git.

The mental model: snapshots, not diffs

The single biggest unlock for understanding git: every commit is a complete snapshot of every file in your project, not a list of changes. Git shows you diffs when it's useful, but under the hood every commit is the full state.

A commit is just a snapshot with a label. The label contains your name, the time, a short message you wrote, and a unique ID. The history of your project is the chain of these commits, oldest to newest.

The minimum vocabulary

• Repository (repo) — a folder that git is tracking. Identified by a hidden .git sub-folder inside it.
• Working directory — the actual files on your disk right now. What you see when you open the folder.
• Staging area — a draft of your next commit. You choose which changes to include before you commit.
• Commit — a saved snapshot with a message.
• Branch — a moveable pointer to a particular commit; a parallel line of development. The default branch is usually called main.
• Remote — a copy of your repo that lives somewhere else (typically on GitHub). You push commits to it and pull commits from it.

A real, complete workflow

Here's the entire happy-path workflow you'll use 80% of the time:

# 1. See what's changed since the last commit
git status

# 2. Stage the files you want to include in the next commit
git add file1.html file2.css

# 3. Take the snapshot, with a short message describing what changed
git commit -m "Add the new homepage layout"

# 4. Push the snapshot up to GitHub so your team can see it
git push

That's the whole loop. Edit, stage, commit, push. Repeat. You can do this hundreds of times a day. The rest of git — branches, merges, rebases — is variations on this theme.

Branches: parallel timelines

A branch lets you work on something without touching the already-good version. Maybe you're trying a redesign you're not sure about. You create a branch called redesign-experiment, do all your commits there, and the main branch stays untouched. If the redesign turns out well, you mergethe branch back into main. If it doesn't, you just delete the branch and nothing on main is affected.

# Make a new branch and switch to it
git checkout -b redesign-experiment

# ... do work, make commits ...

# Switch back to main
git checkout main

# Merge the experiment into main
git merge redesign-experiment

Git vs. GitHub

These are not the same thing.

Gitis the tool. It runs on your computer. It works even with no internet. It tracks your project's history locally.

GitHubis a website (owned by Microsoft) that hosts copies of git repos. It adds collaboration features: pull requests, code review, issue tracking, CI/CD. It is by far the most popular place to put your code, but it isn't the only one — there's GitLab, Bitbucket, Codeberg, and self-hosted options. They all use git underneath.

You can use git without GitHub. You cannot meaningfully use GitHub without git.

How Claude Code uses git

Claude Code is git-aware. When you ask it to make changes, it can run git commands on your behalf — checking status, making commits, creating branches. Most teams use this pattern:

1. Claude makes a set of changes.
2. You read the diff.
3. You ask Claude to commit (or you do it yourself).
4. You push to GitHub when ready.

This is also why git matters even if you don't write much code: commits are your safety net. If Claude takes the project in a direction you don't like, you can roll back to a previous commit and try again. Without git, you'd have no path back.