# Version control > Why version control matters when an agent is editing your work, and how Claude Code does the Git typing for you _20 min · beginner · track: vibe-coding · id: version-control_ > **Team:** > > When you build with AI, the project changes fast. A script that worked > yesterday gets rewritten today. A skill you wrote last week gets 80 lines > added in one minute. The pace is the point, but it also means you need a > real undo button. Not "Cmd+Z three times". A proper one. 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](/course/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. > **Heaven:** Small snapshot when something works. Clear label written by Claude Code, sanity-checked by you. Pushed at the end of the day. Six months later you can pinpoint the exact moment a bug was introduced. > > **Hell:** One giant snapshot at the end of the week called 'updates'. No one, including you, can tell what changed. The history is useless. > **Tip:** > > **Try it.** Open Claude Code in any folder under version control and say: "Show me what has changed today, then commit and push with a sensible message." Watch the diff. Approve each step. ## 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 `` 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](https://docs.gitlab.com/user/ssh/) 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. > **Warning:** > > Once a secret is in the snapshot history, it is in the history forever, even if you delete the file in the next snapshot. The fix when you spot a leaked key is always: rotate the key (assume it is compromised), then clean the history as a separate task. Cleaning the history before rotating the key is doing it in the wrong order. ## 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](/course/ai-first-mindset). 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. ## Quiz **Q1.** You spent 90 minutes guiding Claude Code through a tricky rewrite of your morning routine skill. It finally behaves the way you wanted. You are tired. What is the smartest next move? - a. Close the laptop. The work is saved on disk, that is enough. - b. Ask Claude Code to commit and push with a label that captures what you changed. **(correct)** - c. Wait until you have made a few more improvements so the snapshot is bigger and worth taking. - d. Email yourself a copy of the folder as a backup. _Explanation:_ The moment something works is exactly the moment to lock it in. A small focused snapshot, labelled clearly, is your way back if tomorrow's tweaks break it. Bundling more in dilutes the label, and emailing folders is the renaming-files trap dressed up. **Q2.** A colleague has been improving the same skill as you. You sit down on Monday and want to add a new feature. What do you do before you change anything? - a. Just start working. Worry about your colleague's changes when you upload yours. - b. Ask Claude Code to pull down their latest snapshots so you are working on top of the current version, not last week's. **(correct)** - c. Copy the project folder to a new name to avoid confusion. - d. Message them to confirm they are not editing right now. _Explanation:_ Working on a stale copy means you and your colleague are editing two slightly different projects, and reconciling them later is annoying. Pulling first costs five seconds and avoids the mess. Messaging is fine but it does not replace pulling. **Q3.** You realise the prompt you have been iterating on contains a real API key. You panic. You delete the line and ask Claude Code to commit. Are you in the clear? - a. Yes, the new snapshot replaces the old one and the key is gone. - b. No. Old snapshots still contain the key. Treat the key as leaked, rotate it, then ask Claude Code to help clean the history. **(correct)** - c. Yes, as long as you have not pushed the project online yet. - d. Only if you also empty your trash. _Explanation:_ Snapshots stack. Every previous one still exists in the history, including the one with the key. The fix is always the same order: assume it leaked, generate a new key, and treat the cleanup as a separate task afterwards. ## Hands-on 1. Pick a small project to version, or make a fresh folder if you do not have one: `mkdir ~/projects/my-first-versioned-thing && cd ~/projects/my-first-versioned-thing`. 2. Open Claude Code in that folder. Ask it: `Set up version control here, create a README with one sentence about the project, and take the first snapshot.` Read each step before approving. 3. Edit the README. Then ask Claude Code: `Show me what changed, then take a snapshot with a good label.` Watch the diff before approving the commit. 4. Create a new empty project on GitLab or GitHub. Copy its URL. Tell Claude Code: `Connect this project to the remote at and push.` Refresh the GitLab/GitHub page in your browser. Your work is there. 5. Tell Claude Code: `Add a sensible .gitignore for this project, then commit and push.` Read the entries it picked. Confirm nothing private slips into the next snapshot. ## 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](https://git-scm.com/doc): the official manual. Dense, but the source of truth. - [GitLab docs](https://docs.gitlab.com/): if your team uses GitLab, start here. - [GitHub docs](https://docs.github.com/): if your team uses GitHub, start here.