Save points: git when you have never used it

What git actually is

Git is save points for a folder of files. That is the whole idea. You tell it "remember everything exactly as it is right now," and later you can come back to that exact moment, or see precisely what changed since.

If you have never used it, you have been building without save points, which is why a bad hour can cost you a day.

Git is not a backup service. It is not GitHub. It runs on your machine and works with no internet and no account. GitHub is a place to send a copy, which is a separate step and a separate lesson's worth of value.

The five commands

Open a terminal in your project folder. If your tool did not already set git up, run git init once.

git status
# What has changed since the last save point. Run this constantly.

git diff
# Exactly which lines changed. Green added, red removed.

git add -A && git commit -m "Booking form saves to the database"
# Make a save point of everything, with a note about what it is.

git log --oneline
# Your save points, newest first, each with a short id like a3f9c21.

git restore .
# Panic button. Throw away every change since the last save point.

That is enough to work safely. To go further back:

git reset --hard a3f9c21
# Return the folder to exactly how it was at that save point.
# Everything after it is gone. That is the point of it.

Your editor probably has buttons for all of this. Use them. Knowing the words still helps, because every answer you find online is written in them.

Commit when it works, not when you are finished

This is the habit that matters. The moment a feature does the thing — before you ask for the next change — commit.

A save point is only valuable if the state it holds is good. Ten commits a day, each one a working app, means the worst possible outcome is losing twenty minutes. One commit a week means a bad afternoon costs you the week.

Write the message as what is now true, not what you did: "Bookings can be cancelled by the customer" rather than "changes". In three weeks you will be reading this list to find the last version that worked, and "fixes" and "update" and "asdf" will tell you nothing.

Branches, briefly

git checkout -b payments

That makes a parallel copy where you can try something risky. If it works, merge it. If it does not, git checkout main and the experiment never touched your working app.

You can build real things without ever using a branch. It is worth knowing for the day you want to try a large change without gambling the thing that currently works.

Two warnings

Never commit your secrets. Passwords, API keys, database URLs. Make a file called .gitignore in your project with:

.env
.env.local
node_modules

Do this before your first commit. Once a secret is committed and pushed, deleting the file does not remove it — it stays in the history, and bots scan public repositories for exactly this within minutes of a push. Lesson 8 covers what happens next.

Be careful with `git push --force`. It can overwrite work, yours or a collaborator's. If a model suggests it while you are stuck, ask what it will overwrite before you agree.

The platform's history is not git

Replit, Lovable and Bolt keep their own version history, and it is genuinely useful — a list of checkpoints you can roll back to inside the product.

It is not the same thing. It lives in their account, in their format, and it does not leave with you. When you export your project or move to another tool, that history usually does not come along. Connect the project to a git repository early if the platform allows it. You are not doubting the platform; you are making sure the record of your work is yours.

What good looks like

End of a working session, you should be able to say: my app works, that state is committed, and if tomorrow goes badly I lose tomorrow and nothing else.