The sequel to GitHub without the panic (the prequel). That one got you through the door. This one is for when Claude Code is sitting in your project folder doing the git work, and you would like to know what you are saying yes to.
The whole guide in one line: let Claude type the commands, but you read the diff before any commit and you decide when anything leaves your laptop. Everything else is detail, and almost everything is undoable.
--hard and --force.Throughout, we follow a fictional tutor and a small team of content creators. They make practice-test slide decks. Their loop looks like this:
.pptx) into a project folder.Review.md and Fixes Log.md.my-deck-reviews.Every name, file and folder in this guide is made up. Swap in your own: your-name, my-deck-reviews, and so on.
Claude Code is an AI assistant that lives in a terminal window, inside one folder. Unlike a chat window, it can do things: read the files in that folder, edit them, and run commands such as git.
That is also why it asks permission. Before it edits a file or runs a command, it stops and shows you what it wants to do. You choose.
| You see | What it means |
|---|---|
| Read a file | Looking only. Safe. Usually allowed without asking. |
| Edit / write a file | It will change something in your folder. Check the file name. Git can undo it if you have committed. |
Run git status, git diff, git log | Looking only. Safe. |
Run git add, git commit | Saves a snapshot on your laptop. Reversible. Fine. |
Run git push | Sends your work to GitHub. Slow down and read. |
Run gh repo create | Creates something on GitHub. Check public vs private. |
Anything with --hard, --force, or rm | Can destroy work. Say no, then ask why it needs that. |
Many people choose "allow this kind of command for the session" for the harmless read-only ones, so they are not prompted fifty times. Do that for git status and git diff. Do not do it for push.
A repo starts life as an ordinary folder. git init turns it into a folder with a memory. A commit is one saved snapshot of it.
my-deck-reviews, and drop the first deck into it.You type:
"This folder is a new project. Set it up as a git repo, then show me what would go into the first commit before you commit anything."
A sensible Claude does roughly this, asking before each step:
git init turns the folder into a repogit status lists the files git can seegit add . stages them (picks them for the snapshot)git commit -m "..." takes the snapshotgit add . — the dot means "everything". Before you approve, ask: "What files is that adding?" Section 8 is why.
Nothing has gone online. All of this lives on your laptop, in a hidden folder called .git. Don't delete it; it is the memory.
A diff is the list of what changed since the last snapshot: lines in red were removed, lines in green were added. It is the single most useful thing you can read as a non-programmer, because it answers "what is about to be saved?"
You type:
"Show me the diff of what you changed, in plain English, and wait for my OK before committing."
Claude runs git diff, then summarises. For the deck example it might say: "Three files changed: Review.md is new (a 40-line review), Fixes Log.md is new (six entries), and the v2 deck is a new file. The original deck is unchanged." That last sentence is what you are checking for.
A message is a note to your future self. Short first line, saying what and why.
| Poor | Good |
|---|---|
| update | Review Grade 7 acids deck; log six fixes |
| fixes | Add v2 of acids deck with Q3 answer key corrected |
| stuff | Move scratch notes out of the repo |
You can simply ask: "Write the commit message in the style of the existing ones." It can read git log to match.
Acids Deck (reviewed v2).pptx. Git can already restore old versions, but a clear file name saves a conversation when someone opens the folder.
A branch is a separate line of work. The main line is usually called main. Think of a branch as a photocopy of the project that you can scribble on freely; if you like the result you merge it back, if you don't you throw the copy away.
Use one whenever a change is bigger than a quick fix, or when several people are working at once. In the example, each creator takes their own branch per deck: review-acids-g7, review-metals-g7.
You type:
"Make a new branch called review-acids-g7 and switch to it. Do the review work there, not on main."
git switch -c review-acids-g7 creates and moves to the branchgit branch shows which branch you are on (starred)git switch main goes backLost? Ask: "Which branch am I on, and is there any work not saved?"
A pull request (PR) is a polite way of saying: "I did some work on a branch. Please look at it before it joins main." It is a page on GitHub where the changes are shown as a diff, and where others can comment.
Useful even if you work alone: it gives you one more look at the diff before anything changes on main.
You type:
"Open a pull request from this branch into main. Write the description for a teacher, not an engineer: what changed and which slides I should check."
Claude uses the GitHub command-line tool, gh:
gh pr create --title "..." --body "..." opens the PRgh pr view --web opens it in your browserOpen the link, read the "Files changed" tab, and press the green Merge button yourself when you are happy. Merging is your decision, not Claude's.
gh auth loginBefore gh can do anything on GitHub, it needs to know who you are. You do this once per computer.
gh auth login.gh auth status should say you are logged in.| Private | Public |
|---|---|
| Only you and people you invite | Anyone on the internet, forever (search engines, copies) |
| Right for working drafts, client decks, anything unfinished | Right for finished, generic, share-worthy material |
The team starts private. Their working repo, my-deck-reviews, contains real review history, half-fixed decks and notes about who asked for what. None of that should be public.
But the method is worth sharing: the review checklist, the prompts, the folder layout. So they make a sanitised public copy, a new, separate project. This is not a switch from private to public. Flipping the visibility of the old repo would publish its whole history, including everything deleted months ago.
deck-review-toolkit. Not the whole project.git init in the new folder. Do not copy the .git folder. The public repo starts with one clean commit, and old messages and file names stay behind.You type:
"I want a public copy of the shareable parts of this project in a new folder called deck-review-toolkit. Fresh git history, a neutral git identity (noreply@example.com), and run a case-insensitive grep for my name, email, school, local paths and any tokens before you commit. Show me any hits. Do not create a GitHub repo or push."
.gitignore and secretsGit saves everything it can see. A file named .gitignore lists things it must pretend it can't see. Claude can write it for you.
Three categories that must never be committed:
sk-, or sit in a file called .env).You type:
"Create a .gitignore for this project. Ignore .env files, anything in a folder called private/, student-marks spreadsheets, and temporary files. Then tell me whether any of those are already committed."
.envprivate/*.xlsx~$* and .DS_StoreGood question to ask before every first push: "Is there anything in this commit that I wouldn't want a stranger to read?"
A worktree is a second copy of the project in another folder, linked to the same repo and sitting on a different branch. It lets you or Claude try something risky without disturbing the folder you are working in.
In the example, the tutor keeps teaching from the main folder while Claude reviews a new deck in a worktree. Nothing in the main folder moves under their feet.
You type:
"Do this review in a separate worktree on its own branch, so my main folder isn't touched. Tell me where it is when you're done."
git worktree add ../review-copy review-acids-g7 makes the parallel copygit worktree list shows all copiesgit worktree remove ../review-copy tidies up when mergedClaude Code can do this itself if you ask. If something goes wrong in the copy, delete it. The main folder is fine.
Good news: once something is committed, it is very hard to truly lose. The first move is always the same: stop, breathe, and ask Claude to look before it touches anything.
You type:
"Something went wrong. Don't change anything yet. Run git status and git log, and explain in plain English what state we're in."
| Situation | Recipe | Risk |
|---|---|---|
| Typo in the last commit message, or forgot one file | git commit --amend | Safe if not pushed yet |
| A commit that is already shared turned out wrong | git revert <commit> (adds a new commit that cancels it) | Safe. History stays honest. |
| I messed up one file, want it back as it was | git restore <file> | Discards unsaved changes to that file |
| I want to un-commit but keep my work | git reset --soft HEAD~1 | Safe. Work stays staged. |
| "I lost a commit!" / "I reset too far" | git reflog, find it, then git switch -c rescue <id> | Safe. This is the safety net. |
Git quietly keeps a diary of every place you have been, called the reflog. Even a "deleted" commit is usually still there for weeks.
You type:
"I think I lost the commit where I fixed Q3. Look in the reflog, show me the candidates, and put the right one on a new branch called rescue. Don't touch main."
git reset --hard — throws away uncommitted work permanently. The reflog cannot bring back something that was never committed.git push --force — overwrites what is on GitHub with your version. It can erase teammates' work.Push means "send my commits to GitHub". Until now everything has lived on your laptop. Push is the moment other people (or the internet) can see it.
The first time, you need a remote, the address of the repo on GitHub. For the private working repo:
You type:
"Create a private GitHub repo called my-deck-reviews from this folder and push the main branch. Confirm it is private before you run it."
gh repo create my-deck-reviews --private --source=. --push creates the repo and pushes, privatelygit push is how you send later workBefore you approve a push, check three things on that one line: where it is going, which branch, and that the word --force is not in it. On a first push, also check that --private is there.
Pushing again is fine and routine. Each push just adds your newest commits.
The best control you have is one sentence. Claude does what you say; you only need to say it early.
Phrases worth keeping handy:
For the team, the full loop becomes: download the deck, Claude reviews it and writes the two notes, fixes go into a versioned copy, stop and read the diff, commit, stop and say push. Later, build the sanitised toolkit the same way: scan, commit, stop and read the file list, and only then ask for the public repo.
If you have a CLAUDE.md file in the folder (a note Claude reads at the start of every session), put the standing rules there once: "Never overwrite originals. Never push without asking. Never commit anything in private/."
| repo | one project folder with its memory |
| commit | one saved snapshot, with a note |
| diff | what changed since the last snapshot |
| stage / add | choose which changes go in the next snapshot |
| branch | a separate line of work |
| merge | bring a branch's work back into main |
| pull request | "please look at this before it joins main" |
| remote | the copy of the repo that lives on GitHub |
| push | send commits to GitHub |
| worktree | a second folder on another branch, same repo |
| reflog | git's diary of everywhere you have been; the undo safety net |
| .gitignore | the list of things git must pretend not to see |
| gh | GitHub's command-line helper, used by Claude for PRs and repo creation |
| --hard / --force | the two flags to say no to |