Table of Contents
What this lesson is about
This lesson introduces Git — a system that keeps a permanent record of every change ever made to your files — and shows you how Claude Code can handle all the technical Git commands on your behalf. You will learn how to describe what you want in plain English and let Claude translate that into actions. By the end, you will be able to use Git confidently even if you have never opened a terminal before.
Core concept: Your files, with a perfect memory
Imagine you are working on an important document in Google Docs. Every so often, Google saves a version — and if you ever make a mistake, you can click “Version history” and restore any previous save point. Every word you deleted, every paragraph you moved — it is all there, going back months.
Git does exactly this, but for any file on your computer, not just Google Docs files. It works for Word documents, spreadsheets, website files, code, images — anything. Every time you tell Git to save a snapshot (called a commit, which just means “a saved checkpoint with a description attached”), that snapshot is stored permanently. You can jump back to any of them at any time.
The crucial difference from Google Docs is that you choose when to save a checkpoint, and you write a short description of what changed. This makes it far more powerful — your history is organised by meaning, not just by time.
Why non-developers increasingly need Git
Git was built by software developers, and for many years it stayed in their world. That is changing fast.
Today, marketing teams use Git to track changes to website copy. Operations managers use it to version-control their process documents and templates. Consultants use it to keep a clean audit trail of reports that pass through many hands. Designers use it to track iterations of configuration files.
The reason is simple: once you have experienced being able to say “show me exactly what changed between last Tuesday and today” or “restore the version from before the client asked for those changes” — on any file, not just documents — you cannot imagine working without it.
The barrier has always been the technical commands. Claude removes that barrier entirely.
How Claude handles Git so you do not have to
You describe, Claude executes
Git has its own language of commands — things like git commit, git push, and git diff. Learning these takes time, and typing them incorrectly can feel intimidating.
When you use Claude Code, you never need to memorise a single command. You simply describe what you want in plain English, and Claude works out which Git commands to run, runs them, and explains what happened.
Think of it like this: you are the business owner giving instructions, and Claude is the highly competent assistant who knows all the technical steps. You say what you need; Claude handles the how.
What Claude can do with Git on your behalf
| What you want | What you say to Claude | What Claude does behind the scenes |
|---|---|---|
| See what has changed | “Show me what’s changed since my last save” | Runs git diff and summarises the results |
| Save a checkpoint | “Save my progress with a good description” | Writes a commit message and runs git commit |
| Prepare a change for review | “Write a pull request description for these changes” | Drafts a structured summary of your changes |
| Review before saving | “Check my changes before I commit them” | Reviews the diff and flags anything worth noting |
| Start using Git | “Set up Git in this folder” | Initialises a new Git repository safely |
Asking Claude to summarise what has changed
A diff (short for “difference”) is Git’s way of showing you exactly what has changed since your last checkpoint — which lines were added, which were removed, and which files were touched. Reading a raw diff can look confusing at first, so it is far more useful to ask Claude to summarise it in plain English.
Here is an example prompt you could use:
I've been working on some files in this project and I haven't committed in a while.
Can you look at everything that's changed since my last commit and give me a plain English
summary of what I've done? Group the changes by theme if possible.
Claude will run git diff internally, read through all the changes, and come back with something like:
Here's a summary of what's changed since your last commit:
1. Pricing page (pricing.html): You updated the three pricing tiers — the middle tier
has been renamed from "Pro" to "Business" and the price changed from R499 to R599.
2. Contact form (contact.html): A new phone number field has been added to the form.
3. Footer (footer.html): The copyright year was updated from 2024 to 2025.
No files were deleted. Would you like me to commit these changes now?
This means you always know exactly what you are saving before you save it.
Asking Claude to write a commit message
A commit message is the short description you attach to each saved checkpoint. It is like the subject line of an email — it tells anyone (including your future self) what changed and why.
Good commit messages make your history readable. Bad ones — like “updates” or “fixed stuff” — make it nearly useless when you are trying to find something six months later.
You do not need to write these yourself. Ask Claude:
Based on the changes I've just made to the pricing and contact pages,
write me a good commit message. Keep it concise but descriptive.
Claude might respond with:
Here's a commit message for these changes:
feat: update pricing tiers and add phone field to contact form
- Renamed "Pro" tier to "Business" and updated price to R599
- Added optional phone number field to contact form
- Updated footer copyright year to 2025
I've committed these changes. Your project history now has a clear record of what was done.
The word feat: at the start is a widely used convention meaning “a new feature or improvement” — Claude follows these conventions automatically so your history looks professional.
Asking Claude to generate a pull request description
What a pull request is
A pull request (often shortened to PR) is a formal way of saying: “I have made some changes over here — please review them before they become official.”
In a business context, imagine you have a main version of your website, and a team member has been working on a new landing page in a separate copy. Before that landing page goes live, someone needs to review it. A pull request is the organised, documented way of presenting those changes for review — it includes a summary of what changed, why it changed, and anything the reviewer should pay special attention to.
You do not need to work in a team for pull requests to be useful. Many solo business owners use them as a self-review habit: write the changes, write the pull request description, read it back the next morning with fresh eyes, then approve it yourself.
Asking Claude to draft the description
I've finished updating the About Us page and the team member bios section.
Please write a pull request description that explains what changed, why I made
these changes, and what a reviewer should look at carefully.
Claude will draft something structured and professional, ready to paste into GitHub (the most popular platform for hosting Git projects online) or any other Git hosting service.
Asking Claude to review your changes before they are permanently saved
This is one of the most valuable habits you can build: before committing a checkpoint, ask Claude to look over your changes with fresh eyes.
Before I commit, can you review everything that's changed and let me know if
anything looks like a mistake, if anything is missing, or if the changes are
inconsistent with each other?
Claude will read through the diff, check for things like:
- Placeholder text that was never replaced (e.g. “INSERT PRICE HERE” still sitting in a file)
- Changes in one file that should have matching changes in another file
- Anything that looks like an accidental deletion
- Formatting inconsistencies
Think of it as a proofreading step, but for your entire project, not just a single document. It takes seconds and can save you from committing an embarrassing error into your permanent history.
What to do if you do not use Git yet
Starting fresh — it is simpler than it sounds
If you have never used Git before, the good news is that starting is a single conversation with Claude. You do not need to install anything yourself or read any documentation.
Open Claude Code in the folder where your project lives and say:
I've never used Git before. Can you set up Git in this project folder,
create an initial commit with everything that's here now, and explain
what you're doing as you go?
Claude will:
- Check whether Git is already installed on your machine and install it if needed
- Initialise a new Git repository (a hidden folder called
.gitthat stores all the history) in your project folder - Add all your existing files to the first checkpoint
- Create an initial commit with a sensible description
- Explain each step in plain English as it goes
Your entire project history starts from that moment. Everything you do from that point forward can be tracked, described, and reversed if needed.
A note on safety
Git never deletes your files without being explicitly told to. Setting it up in an existing folder of work is completely safe — it simply begins watching and recording changes from that point forward. Your existing files are untouched.
Practical Exercise
In this exercise you will use Claude to perform a real Git workflow from start to finish, without typing a single Git command yourself.
Before you begin: Make sure you have a project folder open in Claude Code. It does not matter whether it contains real work or test files — any folder will do.
a. Open Claude Code and type the following prompt, replacing the bracketed part with a brief description of your actual project:
I want to start tracking changes to my [describe your project briefly] with Git.
Please set up Git in this folder if it isn't already, then show me a summary
of what files are here and create an initial commit.
Read Claude’s response carefully. Notice that it explains each action before taking it. This is intentional — Claude is designed to keep you informed, not just click buttons on your behalf.
b. Now make a small, deliberate change to any file in your project — even just adding a sentence to a document or changing a word. Then ask Claude to review and commit it:
I've just made a small change to [filename]. Can you:
1. Show me a plain English summary of exactly what changed
2. Review it for any obvious issues
3. Write a good commit message and save the checkpoint
Compare Claude’s summary of your changes to what you actually did. This builds your confidence that the tracking is accurate.
c. Finally, ask Claude to show you your project history:
Can you show me a summary of all the commits in this project so far,
with dates and the messages, laid out in a readable way?
You now have a living, permanent record of your project. Try to repeat steps b and c every time you do a meaningful piece of work — this habit alone will save you hours of “what did I change last week?” confusion.
Common problems and how to fix them
Claude says “this folder is not a Git repository”
This means Git has not been initialised in your project folder yet. This is not an error — it simply means you are starting fresh. Tell Claude: “Please set up Git in this folder and create an initial commit with everything here.” Claude will handle the entire setup.
The commit history looks empty or is missing old work
Git only tracks changes from the moment it was set up in a folder. If you initialised Git today, your history starts today — it cannot recover changes that happened before Git was watching. Going forward, regular commits will build a complete record. If you want to mark a “starting point” that captures everything as it currently stands, ask Claude: “Please create an initial commit that captures the current state of all my files.”
Claude mentions a “merge conflict”
A merge conflict happens when two versions of the same file have changes in the same place and Git cannot work out automatically which one to keep. This sounds alarming but is very manageable. Tell Claude: “I have a merge conflict — can you walk me through resolving it and explain what’s happening?” Claude will show you both versions of the conflicting section and help you decide which to keep.
You committed something you should not have
If you accidentally committed a file that should not be in your history (for example, a file containing a password or sensitive information), tell Claude immediately: “I accidentally committed a file called [filename] that contains sensitive information. How do I remove it from the history completely?” Claude will walk you through the appropriate steps. Act quickly — the sooner you address it, the simpler the fix.
Git is asking for your name and email address
The first time Git runs on a machine, it asks who you are — this information is attached to every commit you make, so the history always shows who made each change. This is normal and harmless. Tell Claude: “Git is asking me to set up my name and email — can you do that for me?” and provide your name and preferred email address when Claude asks.
What you have learned in this lesson
- Git is a version-control system that keeps a permanent, detailed record of every change ever made to your files — like Google Docs version history, but for any file on your computer
- You do not need to learn Git commands — Claude can run them all on your behalf based on plain English instructions
- A commit is a saved checkpoint with a description; a commit message is that description, and writing clear ones makes your history far more useful
- Claude can read your changes and summarise them in plain English before you commit, so you always know what you are saving
- A pull request is a structured, documented way of presenting changes for review — useful both in teams and as a solo self-review habit
- Asking Claude to review your changes before committing is a simple habit that catches mistakes before they become permanent
- Setting up Git in an existing project is safe and straightforward — Claude can do it in a single conversation, and your existing files are never touched