Git vs GitHub, explained for people who build with AI

You already do version control, just badly

Have you ever saved a file called “Final V2, Actually Final”? That’s version control, done by hand. It works for one file, sort of. But a website, a knowledge base or an app isn’t one file. It’s a folder full of them, and when someone edits a page and it breaks, there’s no way back to how it looked this morning.

Developers have had proper versioning for decades, and it costs nothing to use. It just stayed behind a command line that kept everyone else out.

What is Git vs GitHub

Git lives on your computer and keeps the full history of your project: every change, who made it and when. GitHub is an online home for that history, so it’s backed up, you can share it, and a tool like Claude or a hosting service can work from it.

How Git stores your work

Git doesn’t keep a full copy of your folder every time you save. It stores only what changed, line by line. That’s why you can keep a huge number of versions of any kind of file and it costs almost nothing.

It also lets you work on a copy beside the live version. You try your change there, and when it works you merge it in. If the live version ever breaks, you point back to the last good one and it’s live again in moments.

GitHub for vibe coding: save points for AI edits

This is why Git matters more now than it used to. AI writes pages, and AI breaks them. It fixes the thing you asked about and quietly changes something else, and without history there’s no undo.

With Git, every change the AI makes is a save point. If it breaks your booking page on the third try, you go back to the second. That’s what makes it safe to let AI try things at all.

Using Git without the command line

The command line is what kept most people out of Git, and that barrier is mostly gone. You can tell Claude in plain English, “save this version with a note saying I fixed the booking form”, and it runs the Git commands for you. I haven’t typed a Git command by hand in a year or two. I still use Git on everything I build.

If you’d rather click than type, GitHub Desktop and the Git panel in VS Code do the same job with buttons.

Git vs GitHub vs GitLab

GitLab and Bitbucket are alternatives to GitHub: other websites that store your Git history online. Git itself is the same underneath all of them. For someone starting out and building with AI, GitHub is the one most tools connect to first, so it’s where I’d start.

Git vs GitHub Desktop

GitHub Desktop isn’t a third thing. It’s an app with buttons for using Git and GitHub, so you don’t have to type commands. It’s a good middle step if you don’t want to hand everything to an AI yet.

Git flow vs GitHub flow

These two names sound like the same thing and aren’t. Git flow and GitHub flow are two ways a team agrees to use Git. They’re working habits, not products.

Git flow has two long-lived lines of work: a main version that’s live and a development version where changes come together. Around them sit short-lived branches (side copies) for new features, releases and urgent fixes. It’s built for software with numbered versions, sometimes several in use at once.

GitHub flow is simpler: one main version, a short branch for each change, merged back through a pull request. A pull request is a request to add your change, with a place for someone to review it. Your change doesn’t reach main until you merge it. GitHub’s own guide says this flow “is useful for everyone, not just developers.”

For a simple site or a first app, GitHub flow is the better fit. It’s fewer rules, and the AI can follow it without confusion. The simple rule I’d use: one live version, a working copy for each change, and a check before the change goes live.

Vincent Driessen, who wrote the original Git flow post, added a note in 2020. He wrote that web apps are “typically continuously delivered” and that for teams doing continuous delivery, “I would suggest to adopt a much simpler workflow (like GitHub flow).”

Read more: GitHub’s guide to GitHub flow and Vincent Driessen’s original Git flow post.

How I set Git up for people who aren’t developers

I once ran the website for an international dental students’ association where most of the people who wanted to help weren’t developers. So I wrote a Git workflow simple enough for volunteers: one main version that’s live, one working copy for changes, and a clear rule for moving changes from one to the other. The same idea works for a small business site today, except now the AI does the typing.