Git basics for non-developers using Claude Code

Git is the system that records every change to your website's files, who made it and when, and lets you go back to any earlier version. If Claude Code is going to edit your site, git is your real undo button. You don't need to become a git expert. You need about eight words, a handful of commands you can recognize when Claude runs them, and one setting on GitHub that stops anyone, human or AI, from changing your live branch without review.

Claude Code can run git for you in plain English: "create a branch", "commit my changes", "show me the last five commits". That's convenient, and it's also why you should know what those requests do. This guide covers the basics for owners, marketers and content people as of October 2026, with the prompts to use and the checks that prove each one worked.

Why git matters more once Claude Code is involved

Claude Code saves a checkpoint each time you send a prompt, and you can rewind with /rewind. That's useful, but Anthropic is clear about the limits: checkpoints "don't track changes made through the Bash tool" (the shell commands Claude runs), and "actions that affect remote systems (databases, APIs, deployments) can't be checkpointed." Anthropic's own docs say checkpoints are for quick, session-level recovery, and point to version control such as git for permanent history.

There's a second reason. A coding agent can change many files quickly. Git turns that into something a person can review: a list of changed files and the exact lines that changed, before anything goes live. Without git, you're trusting a summary. With it, you're reading the record.

The eight words you need

More terms, Claude Code ones included, are in our Claude Code glossary.

What a safe change looks like in git

Every Claude Code task on a website can follow the same path. Once you've done it a few times, it takes little thought.

1. Start fresh. Ask: Switch to main, get the latest changes, then create a new branch called fix-contact-page-typo. Check: Claude reports the new branch name.
2. Do the work. Claude edits files on the branch. Main is untouched.
3. Review. Ask: What files have I changed? Then open the diff (/diff in the terminal, or the diff view in the desktop app).
4. Commit. Ask: Commit these changes with a descriptive message. Check: Show me the last 3 commits.
5. Push the branch, not main. A person, or Claude after you approve the prompt, pushes the branch to GitHub.
6. Open a pull request. A reviewer reads the diff on GitHub and approves it or asks for changes.
7. Merge and deploy. Only after approval. If something goes wrong, revert.

The example prompts above are like the ones in Anthropic's quickstart. They aren't magic words; any clear request works. Our walkthrough of a first Claude Code session puts this loop into practice.

Commands worth recognizing

When Claude asks permission to run a git command, you should know roughly what it does. Here are the common ones, with descriptions from git's own documentation.

Claude Code's auto mode blocks some of the riskiest ones by default. Anthropic's list of actions blocked by default includes force pushes, git reset --hard and git restore . when they would discard uncommitted work. It does not block ordinary pushes. Anthropic's auto mode configuration page says auto mode "allows pushes to any branch of the repository you're working in, including the default branch."

Make pushes ask first

Because a push to main can be a live deploy, add a permission rule so Claude Code always asks before pushing or opening a pull request. Anthropic documents that ask rules "always force a permission prompt, even in auto mode." In the project's .claude/settings.json:

{
"permissions": {
"ask": ["Bash(git push *)", "Bash(gh pr create *)"]
}
}

A rule like this matches the command as written, so a variant such as git -C . push slips past it. It's a strong guard against accidents, not a lock. That's why the GitHub setting in the next section matters too. Our guide to using Claude Code safely on a live site covers the full settings file.

Undoing things: which tool for which mistake

Notice what's missing: nothing in that table rewrites history. Reverting keeps the record of what happened, which is what you want on a business site. Our guide to checkpoints and rewind explains exactly what rewind can and can't restore.

If your site deploys from GitHub, a merge into main is usually what starts the deploy. Our guide to deploying GitHub projects to Vercel shows how that connection works on one common host.

Protect main on GitHub

Branch protection is a GitHub setting that puts rules on an important branch. A repository administrator adds a rule for main under the repository's Settings, then Branches. Ideally choose these options:

• Require a pull request before merging, with Require approvals turned on. With required reviews, GitHub says collaborators "can only push changes to a protected branch via a pull request that is approved by the required number of reviewers with write permissions."
• Require status checks before merging, if you have automated checks (such as a build) that run on each pull request. See our guide to website QA with Claude Code in GitHub Actions.
• Apply the rules to administrators too. By default, the rules "don't apply to people with admin permissions to the repository," so an administrator can merge a pull request that doesn't meet them. In the rule's settings, the option to close that gap is labeled "Do not allow bypassing the above settings." If the person running Claude Code is an admin, turn it on.

Each protection rule also disables force pushes and branch deletion by default. Availability: protected branches work on public repositories with GitHub Free, and on private repositories with GitHub Pro, Team or Enterprise. Check the GitHub branch protection docs for your plan.

Two more GitHub basics for website repositories. A .gitignore file in the repository root tells git which files never to commit; your environment files with passwords and keys belong in it. And GitHub's push protection "blocks pushes that contain secrets before they reach your repository." The version tied to your own account is on by default and covers pushes to public repositories; the repository-level version, which covers everyone pushing to a repository, needs GitHub Secret Protection and is off by default. Our guide to keeping secrets away from Claude Code covers the rest.

Prefer clicking? GitHub Desktop

If the command line puts you off, GitHub Desktop is "a free, open source application that helps you to work with files hosted on GitHub or other Git hosting services," for Windows and macOS. GitHub says it has a graphical interface that "helps you visualize changes." A practical split for a non-developer: Claude Code does the work on a branch, and you use GitHub Desktop to look at the changed files, the history and the branches. You can also review pull requests on GitHub.com, in the Files changed tab.

Git habits from running eseospace.com

When we rebuilt eseospace.com with Claude Code, two git habits mattered more than any others. First, check git history for changes you didn't make before you deploy. Once, two Claude Code sessions worked on the same site, one regenerated pages the other had just edited, and those edits disappeared. The history showed it; a quick look at the live site didn't. Second, make edits in the source files, not the generated output. A publishing step that rebuilds pages from source will wipe out anything edited only in the built copy.

A prompt that covers the first habit: Before I deploy, run git log on this branch and list any commits I didn't make.

Conclusion

You don't need to master git to use Claude Code safely. You need to work on a branch for every task, read the diff before committing, make pushes ask first, protect main with required reviews, and know that revert is how you undo something already shared. Set those up once and every Claude Code change becomes something a person can see, judge and reverse. If you'd like help putting a repository, branch protection and permission rules in place for your team, our Claude Code consulting covers that setup. More guides are in our Claude Code Guide.

Frequently asked questions