Git for Beginners (AI Edition): Never Lose a Working Version

Git is a save system for your project folder. Commit every time the app works, and you can get back to that exact version whenever an AI agent breaks something. You only need about five commands to start, and you can ask your agent to run most of them.

This guide is the short version of git for beginners using AI tools. It leaves out the parts you don't need until you work on a team.

Why your AI editor's undo button isn't enough

Cursor, Claude Code and similar tools have built-in undo. It's handy, but it isn't history. Cursor's docs say checkpoints are stored locally and separate from Git. They also say to use them only for undoing agent changes and to use Git for permanent version control.

Claude Code is similar. Its checkpointing docs say it doesn't track files changed by bash commands. They also say your manual edits outside the session are normally not captured. Their suggested mental model: checkpoints are "local undo" and Git is "permanent history".

So the undo button covers the last few prompts, in one session, for edits the agent made with its own editing tools. A commit covers everything and sticks around until you delete it.

The mental model in four words

• Repository (repo): your project folder, plus a hidden .git folder where the history lives.
• Commit: a saved snapshot with a short note. Think of it as a save point in a game.
• Branch: a separate line of save points. Use one when you want to try something risky.
• Remote (GitHub): a copy of your repo online, so a dead laptop doesn't take your project with it.

That's enough vocabulary to start.

Step 1: Install Git and turn your project into a repo

Check whether Git is already installed:

git --version

If you get a version number, you're set. If not, install Git from git-scm.com. Then, in your project folder:

git init
git add .
git commit -m "first working version"

If Git complains that it doesn't know who you are, set your name and email once:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Many AI app builders and editors already run git init for you. Run git status to check. If it says "not a git repository", do the steps above.

Do this before the first commit: a .gitignore

A .gitignore file tells Git which files to skip. Two things should almost always be on the list: secrets and bulky generated folders. A typical web project starts like this:

.env
.env.local
node_modules/
dist/
.next/

If an API key gets committed and pushed, assume it's compromised and rotate it. Ignoring .env up front is much easier.

Step 2: Commit every time something works

This is the habit that matters. The rhythm looks like this:

1. Ask the agent for one change.
2. Run the app and click around.
3. If it works, commit. If it doesn't, undo or ask for a fix.

The commit takes ten seconds:

git add .
git commit -m "login form works"

Write messages for future-you at 1 a.m. "Login form works" is better than "update". "Working, before switching to Stripe" is better still.

Or let the agent do it

You don't have to type this yourself. Paste this into your agent's chat once, or add it to your project rules file:

Before you start any task, run git status. If there are uncommitted
changes, commit them with a short message describing the last working
state. Make changes in small steps. After I confirm something works,
commit with a clear message. Never run git reset --hard, git clean,
or force-push without asking me first.

That last sentence matters. Those commands can delete work permanently, and an agent trying to "clean up" shouldn't have a free hand with them.

Step 3: Use a branch for risky experiments

Want to try a redesign, swap your database, or let the agent attempt a big refactor? Make a branch first:

git switch -c try-new-dashboard

Work there as long as you like. If it's a mess, go back to your stable line and forget the experiment:

git switch main

If you like the result, merge it in. You can ask the agent to do that:

git merge try-new-dashboard

Your original branch is name main on most modern setups, but older repos sometimes use master. git branch shows you which you have.

Step 4: Undo things when the agent breaks stuff

Which command you need depends on what state the change is in. Since Git 2.23, git restore handles files and git switch handles branches, which is clearer than the old catch-all checkout.

What happened	Command	Safe?
See what changed since your last commit	git status and git diff	Yes, read-only
One file got wrecked, you haven't committed	git restore path/to/file	Discards that file's uncommitted edits
Everything is wrecked, back to last commit	git restore .	Discards all uncommitted edits
Bring back one file from an older commit	git restore --source=abc1234 path/to/file	Overwrites the file in your folder
Look at your save points	git log --oneline	Yes, read-only
Undo a commit you already pushed	git revert abc1234	Adds a new commit, keeps history
"I think I lost something"	git reflog	Yes, read-only

The abc1234 bit is a commit ID. git log --oneline prints them next to each message.

The commands that discard changes, like git restore ., don't ask for confirmation, and uncommitted work can't be brought back. That's the whole argument for committing often. If you're unsure, run git diff first and read what you're about to throw away.

A recovery routine that works

1. Stop prompting. Another "fix it" message usually makes things worse.
2. Run git status to see what's changed.
3. If the current state has anything you might want, commit it on a new branch first: git switch -c rescue-attempt then git add . and git commit -m "broken but saving".
4. Go back to the last good commit with git switch main (or wherever it was).
5. Re-prompt, with a smaller request.

Step 3 costs you thirty seconds and takes the fear out of everything after it.

Step 5: Push to GitHub so a dead laptop isn't the end

Local commits protect you from bad prompts. They don't protect you from a spilled coffee. For that, push to GitHub. GitHub's quickstart walks through creating a repository and making your first commit. Make the repo private unless you want strangers reading your code.

Once the empty repo exists, GitHub shows you the commands to connect it. They look like this:

git remote add origin https://github.com/your-username/your-repo.git
git branch -M main
git push -u origin main

After that, git push sends new commits up. Do it at the end of every work session, or ask your agent to.

If the command line puts you off, GitHub also makes a desktop app. Its official guide says you can create and manage a repository without the command line.

Common mistakes

• Committing a broken state with a happy message. Test first. A commit labelled "working" that isn't defeats the point.
• Giant commits. If you commit once a day, you can only go back a day. Commit per feature or per fix.
• Letting the agent run wild on main. For anything big, make a branch.
• Trusting only the undo button. It's a convenience. Commits are the safety net.
• Pushing secrets. Check .gitignore before your first push.

FAQ

Do I need Git if my AI tool has checkpoints or rewind?

Yes. Checkpoints are session-based and limited to what the agent itself edited, as the Cursor and Claude Code docs describe. They're good for "undo the last prompt". Git is what saves you after a crash, a bad update, or a change you only notice three days later.

How often should I commit?

Whenever something works and you'd be annoyed to lose it. For most people that's after each small feature or fix, often several times an hour in a busy session. Small, frequent commits give you more places to go back to.

Is Git the same thing as GitHub?

No. Git is the version-tracking tool on your computer. GitHub is a website that hosts copies of Git repositories online. You can use Git with no GitHub account at all, but adding GitHub gives you an off-machine backup.

Cover photo: Avtar Singh on Unsplash