A 10-minute interactive guide to Git
I believe the way we work in companies is about to change fundamentally. One big reason: vibe coding. Anyone can now build a custom tool for their own problem. No engineering degree, no ticket in somebody's backlog. Just you, an AI and an idea.
But there's a catch. The boring stuff suddenly matters. Things like version control. The moment you build something together with engineers — or just want to hand your thing over to one — you need to speak a bit of Git.
Sure, your AI does roughly what you ask. But it never hurts to understand the principle. Then you can tell it how to solve a problem, instead of hoping it guesses right.
So here's Git for everyone who isn't an engineer. Ten minutes, six concepts, no terminal needed.
You only need six things
Use the bar at the top of the guide to move between steps. Every step has a little sandbox: press the buttons (the glowing one is a good next move) and hover or tap the numbered dots to see what's going on. You can't break anything here. Promise.
Interactive guide
6 steps · about 10 minutes
Step 1 of 6
Commit
A commit is a save point. Like in a video game — except you can jump back to any of them, whenever you want.
Each commit stores a snapshot of your files, a short message about what you did, who did it and a unique ID. Git never saves on its own. You decide when something is worth a save point.
It's two moves: pack your changes with git add, then seal the box with git commit. Try it.
Try it
1HoverTap the numbered dots to see what's going on
Your move · the glowing button is a good next step
This is a folder on your laptop with one file in it. Start by changing something.
Step 2 of 6
Branch
main is the official version of your project. Usually the one that's live. You don't experiment on it.
Instead, you create a branch — your own parallel line where you can mess around without breaking anything for anyone. And here's the fun part: a branch isn't a copy. It's just a sticky note pointing at a commit. That's why they're free. Make as many as you like.
Create one, commit on it, then switch back to main and see what happens.
Step 3 of 6
Merge
Your experiment works. Now you want it in main. That's a merge.
Git looks at both lines, combines the changes and ties them together with a merge commit — a commit with two parents. If nobody touched main in the meantime, it's even simpler: Git just slides the main sticky note forward. That's called a fast-forward.
Try both scenarios.
Step 4 of 6
Git vs GitHub
People mix these up all the time. Quick fix:
Git is the tool. It runs on your laptop, keeps the whole history and works without internet.
GitHub is a website that hosts a copy of your project so everyone can sync — plus all the people stuff on top: pull requests, reviews, comments. GitLab and Bitbucket do the same thing.
Think of Git as the version history and GitHub as the shared drive. You push to upload your commits. Your colleague does a pull to get them.
Step 5 of 6
Pull request
A pull request (PR) is you raising your hand: "I did this on my branch. Can someone have a look before it goes into main?"
It's a GitHub thing, not a Git thing. It's where colleagues review your change, robots run tests and someone finally presses the merge button. Pretty much every team works like this — and honestly, it's the best place to learn. You'll pick up more from review comments than from any tutorial.
Click through the life of a PR.
Step 6 of 6
Merge conflict
Sounds scary. Isn't.
A merge conflict happens when two people changed the same line in different ways. Git is smart — it merges everything else on its own — but it won't guess who's right. So it stops and asks you.
It's not an error. It's a question. Answer it, commit, done.
House rules for commits
Super short, I promise.
- Commit often. Save points are free. Future you will be grateful.
- Keep them small. A small commit is easy to review and easy to undo. A giant one is neither.
- One thing per commit. "Fix login bug" — not "fix login, new logo and some cleanup while I was at it".
- Use conventional commits. Start the message with the kind of change:
feat: add pricing page,fix: broken signup link,docs: update readme. Humans and robots can read your history at a glance.
The best part: you can tell your AI exactly that. "Commit after every step, keep commits small, use conventional commits." It will happily do it.
The bit worth remembering
You don't need to know Git by heart. You need to know what it does — so you can ask for the right thing.
Addendum: "never on main" isn't a law
In the branch step I said you don't experiment on main. That's the safe default — not the only way. Teams work very differently depending on how big they are and how they collaborate:
- Feature branches + pull requests. What this guide shows. A great default, especially when people work remotely, in different time zones, or are new to a codebase.
- Trunk-based development. Everyone commits to main many times a day and branches live for hours, not weeks. Needs solid automated tests and often feature flags to hide unfinished work.
- Extreme Programming (XP). Two people (or the whole team) write code together, in tiny steps, tests first, and integrate into main continuously. The review happens live while you type, so there's no PR to wait for. Works brilliantly for small teams that sit together.
- Git flow. Long-lived branches for development and releases. Heavier, but useful when you ship versions on a schedule, like apps or software people install.
No single one is right. Two people pairing all day need different rules than 200 engineers across three continents. Start with branches and PRs — then ask your team how they do it.