Git and versions

This lesson is still being tested: it improves with learners' feedback. If something is unclear, it is the lesson that needs fixing, not you.

By the end of this lesson, you will be able to

save a version of your tool at each step that works;
write a .gitignore for what must never be saved;
see what has changed since the last version;
go back to the last version of a file, knowing what you lose.

Why it matters to you

An agent changes things fast, sometimes too fast. With saved versions, no change is serious: you know what changed, and you can go back. In module 5, you discovered Git for your folder. Here, you turn it into the builder’s habit: a version after each step that works, and a file that says what Git must never keep.

Before you start


You need	Claude Code (app or terminal), in Manual mode, Git installed (module 5, lesson 6), and your project folder
Cost	Git is free; the agent requires its subscription (Claude Pro at minimum: €18 per month excl. VAT billed monthly, or €15 per month excl. VAT with the annual plan of €180 paid up front; prices shown on claude.com/pricing on 24/10/2026)
Duration	60 minutes
Reminder	Git keeps the whole history: a secret saved once stays in it (lesson 6)

Understand it in 3 minutes

The rhythm: try, check, save. One version (a commit) after each step that works, with a message that says what changed: “Added the Export button”, not “changes”.

The .gitignore lists what Git must not track: the .env file for secrets, data backups, personal files. According to the Git documentation (24/10/2026), it has no effect on files that are already tracked: it is set up before those files are saved for the first time.

Three commands to know (the agent runs them for you; according to the Claude Code documentation, the forms of git that only read run without a request, but those that change something, like git restore, ask for your approval):

Command	What it does
`git status`	According to the Git book, it is the main tool for knowing the state of the files
`git diff`	Shows the changes not yet “staged” for the next version (`git diff HEAD` shows everything that changed since the last version)
`git restore <file>`	Puts the file back in the state of the last saved version

Careful with git restore. The Git book warns: it is a dangerous command; any local change to the file is lost, Git replaces it with the most recently saved version. What was never saved with Git cannot be recovered with Git.

Do it together

1Step 1: The .gitignore, then the first version

First of all: check that Git is installed (git --version in the terminal; if not, module 5, lesson 6, explains how to install it). Then set the name and the address that will be saved in each version: they will become public if you ever publish the project (lesson 7).

According to the official Git book, this is done once, with git config --global user.name "Your name" and git config --global user.email your.address@example.com: choose what you accept to show.

In Claude Code, on your project folder, in Manual mode:

Put this folder under Git: first create a .gitignore file that excludes the .env file and my data backups (only the tool's backup files, for example carnet-emprunts-*.json, not all .json files), then save a first version of the other files, with a clear message.
Then show me the result of git status and git log --oneline.

Read each permission request before accepting.

In our test on 24/10/2026, with a request that only said “the .json backup files”, the agent created the .gitignore, saved the first version, then warned that the *.json rule excludes all .json files, not only the backups: hence the wording above, which names the backups. Afterwards, a .env file and a .json backup added to the folder did not appear in git status: they were indeed ignored.

2Step 2: See what has changed

Make a small change to your tool (lesson 2), then:

Show me what has changed since the last version, in plain language. Do not change anything.

If the change works (redo the tests), save a new version: “Save a version with the message: [what changed].”

3Step 3: Go back

To practice, safely first: ask the agent “Run git status and tell me if there are any unsaved changes”. If there are, save a version first (step 2). Even better, do the exercise on a copy of your folder. Only then, deliberately damage your tool (for example, ask “replace the whole content of [name].html with a single line: oops”). Then:

I damaged [name].html by mistake. Go back to the last saved version of this file only, without touching the other files. Tell me what you did.

In our test, the agent first looked at git status and git diff, then ran git restore -- prets.html (prets.html was the file in our test: on your side, it will be the name of your file): the file came back identical to the saved version. It warned that the damaged version, never saved, could not be recovered.

A special case: if the agent had already “staged” the damaged file for the next version (the git add command), a plain git restore would leave it damaged, because by default it puts the file back as it is in that staging area (according to the Git documentation). In that case, ask for it to be restored from the last saved version: the full form is git restore --source=HEAD --staged --worktree <file>.

Your turn

Put your project under Git, with a .gitignore set up before the first save.
For a week, save a version after each step that works, with a clear message.
Practice going back on a file once.
Write the messages of your versions in your journal: it is the story of your tool.

Check your work

It worked if:

git log --oneline shows several versions, with clear messages;
the .gitignore exists, and .env as well as the backups do not appear in git status;
you know how to ask what has changed since the last version;
you managed to go back, and you know what it makes you lose.

Common mistakes:

saving a version that does not work;
setting up the .gitignore after saving .env;
messages like “changes” or “test”;
running git restore without knowing that unsaved changes will be lost.

Keep it and pick it up later

Before each change you ask the agent for: a version. After, if it works: another one.
Git does not replace your copies (module 5, lesson 6): the .git folder is inside your folder, on the same disk.

Going further

optional

According to the Git documentation, for a file that is already tracked to stop being tracked, you must remove it from the index with git rm --cached, then add it to the .gitignore. For a secret, that is not enough: it stays in the previous versions (lesson 6).

New words

4 words explained

Word	What it means
Version (commit)	A record of the state of your files, with a message
.gitignore	The list of files Git must not track
History	The sequence of all your versions, with their messages
Going back	Putting a file back in the state of a saved version

Date, version, sources Written on 24/10/2026. Checks on 24/10/2026:

git status, the main tool for knowing the state of the files: git-scm.com, Git book, “Enregistrer des modifications dans le dépôt” (in French);
git restore, replacement with the last saved version, dangerous command: git-scm.com, “Annuler des actions” (in French);
.gitignore with no effect on already tracked files, git rm --cached: git-scm.com/docs/gitignore;
Git is free: git-scm.com;
price of Claude Pro: claude.com/pricing.

Steps 1 and 3 were actually run with Claude Code 2.1.310, git commands only, in an isolated test folder (test report, T56). The request in step 1 was run with its original wording (“the .json backup files”); the current, more precise wording was not run again. The test sessions with Claude Code were run in non-interactive mode (claude -p), once each: what you see may differ (permission requests, wording, number of questions).