Version control

That undo button is called version control. The tool is Git. You do not need to be a developer to use it, but it can feel a bit technical and overwhelming if you are not used to working with code. The trick is that you do not actually run Git yourself. Claude Code does that part. You stay in the loop on what gets saved and when.

The mental model is simple: every time you reach a moment where the work is in a state you would want to come back to, you take a snapshot. Days, weeks, or a year later, you can step back to that exact snapshot and start again from there. Nothing is ever truly lost. Every change is labelled with who made it and why.

How this looks day to day

You almost never run a Git command yourself. You ask Claude Code in plain English.

Show me what changed, then commit it with a sensible message and push.

Claude Code runs git status and git diff to see what you changed, writes a real commit message that captures the why, then runs git add, git commit, and git push, asking for your approval at each step. You stay in charge: you read what it did before you say yes. You are not memorising syntax.

This is the right division of labour. You decide when to take a snapshot and roughly what it should say. Claude Code handles the keystrokes.

What Git is doing under the hood

Knowing the five core Git verbs makes your asks more precise, even though Claude Code does the typing.

• git status: shows what changed since the last snapshot. Run this first, every time. Did the agent rewrite three files or thirty?
• git add: picks which changes go into the next snapshot. Most of the time you want all of them; if you have been working on two unrelated things, this lets you separate them.
• git commit -m "...": takes the snapshot and labels it. The message is the why, not the what. “Add reminder loop to morning skill” reads well six months later. “Updates” does not.
• git push: uploads your local snapshots to the remote (GitLab, GitHub) so they exist in more than one place.
• git pull: downloads any snapshots a colleague pushed since you last looked, so you start from the latest version.

Claude Code reaches for these in the order that makes sense for the ask. You can stop it between steps and adjust.

Local and remote

Your project lives in two places at once: a local copy on your laptop and a remote copy hosted online.

The local copy is where you actually edit, where Git keeps the full history of every snapshot, and where you can keep working when the wifi is down. If the project is small and only yours, your laptop can be the only home it has.

The remote copy is the same project hosted on GitLab or GitHub. Think of it as the team’s shared copy. It is also a backup if your laptop dies. It is the place a colleague reads your changes before they merge into the official version. That review step is what people mean by the “four eyes” rule.

Local and remote stay in sync because you push when you are ready to share and you pull before you start your next round of work. Most of the time, your local copy is a little ahead of the remote (you have new snapshots not yet pushed) or a little behind (your colleague pushed something you have not pulled yet).

Setting up a remote and a .gitignore

Two one-time-per-project steps make Claude Code’s git work pleasant: connect the project to a remote, and tell Git what never to track.

Create a remote. On GitLab or GitHub, create an empty project and copy its URL. In the project folder, ask Claude Code: “Connect this project to the remote at <paste URL> and push the current state.” It runs git remote add origin ... and the first push for you. After that, every git push reaches the remote without further setup.

If your team uses GitLab and you have not set up SSH keys yet, run ssh-keygen -t ed25519 -C "your.email@company.com" once, paste the contents of ~/.ssh/id_ed25519.pub into your GitLab profile under SSH Keys, and you will not have to type a password every push. The GitLab SSH docs walk through it.

Add a .gitignore. Some files never belong in version control: secrets like .env files with API keys, dependency folders like node_modules/ that can be reinstalled, OS junk like .DS_Store. Tell Claude Code “add a sensible .gitignore for this project” and it picks the right entries based on what is actually in the folder.

Why this matters more with AI

Without AI, you might touch fifty lines a day. With AI, you can touch five thousand. The ratio of “stuff changing” to “your attention” goes way up. Version control is what keeps that ratio honest. If something breaks, you can step back. If a colleague asks “why is this here?”, you have a record. If the agent made a confident mistake five snapshots ago, you can find it.

This ties straight back to the “you are responsible” rule. Claude can write a thousand lines, but the snapshot is still yours. The label on the snapshot is yours. The decision to ship it is yours. Version control is one of the tools that lets you actually own that responsibility instead of pretending to.

Check yourself

3 quick scenario questions. Pick the best fit, see why.

Start quiz

Hands-on

Reflect

• Pick a project on your laptop right now that is not under version control yet. What is the one thing stopping you from asking Claude Code to put it under version control this week?
• The next time you ask Claude Code to make a non-trivial change to a project, are you going to take a snapshot before, after, or both? Decide now, before you forget.

References

• Git documentation: the official manual. Dense, but the source of truth.
• GitLab docs: if your team uses GitLab, start here.
• GitHub docs: if your team uses GitHub, start here.