GitHub 101, made practical

The one rule that matters most

If the project is already on GitHub, tell Claude before any change.

Claude cannot see your GitHub history unless you point it there. If work already exists online, say so and give Claude the link, then ask it to pull the latest version first. This single habit stops your existing work from being overwritten or duplicated.

What to do, in order

Six steps. You speak in plain English. Claude does the technical work.

1

Tell Claude what already exists

Before anything else, say whether the project is already on GitHub. If it is, hand over the link and ask Claude to pull the latest. If it is new, ask Claude to set it up.

Say: "This is already on GitHub at [link]. Pull the latest before we change anything."

2

Ask for a branch before risky work

When you are about to try something that could break things, ask Claude to make a branch first. Your trusted version stays safe.

Say: "Create a branch before we try this, so main stays safe."

3

Work, then ask Claude to save

Make your changes as normal. When you reach a good point, ask Claude to commit with a clear message. Each commit is a snapshot you can return to.

Say: "Commit this with a clear message describing what we did."

4

Send it up to GitHub

Once your work is committed, ask Claude to push. Your work is then backed up and available to others.

Say: "Push our work to GitHub."

5

Check where you stand whenever unsure

If you lose track, ask Claude for the current state. It will tell you which branch you are on and whether you are up to date. You never have to guess.

Say: "What is the current status? Am I up to date with GitHub?"

6

If something breaks, ask to go back

Nothing is truly lost while history exists. Ask Claude to return to the last working commit and it will undo the damage.

Say: "Something broke. Take us back to the last working commit."

The practical rules

Keep these six and you will avoid almost every common mistake.

Rule 1

Tell Claude if the project is already on GitHub, before any change. Ask it to pull first.

Rule 2

Ask for help. Describe the outcome you want in plain words and let Claude run the commands.

Rule 3

Pull before you push. Get the latest from GitHub before adding your own work.

Rule 4

Branch before risky work. Keep main working at all times.

Rule 5

Commit often, with honest messages. Small, clear snapshots are easy to return to.

Rule 6

When in doubt, ask Claude for the status before doing anything else.

Say it to Claude

You do not need to memorise these. Copy the one that fits your moment and paste it to Claude. Replace anything in [square brackets] with your own detail.

The approach

You never touch Git. Claude does all of it.

No branches, no commits, no merges typed into a terminal. Your only habit is the first line you type in a new chat, and reading a plain-English summary before you approve anything.

One question decides everything

Before you start, ask yourself which of these two things you are doing. The answer determines whether GitHub is involved at all.

Work

Using your tools to produce something. A draft, a report, an email, a spreadsheet, an analysis.

Nothing to merge. You approve the output and you are done.

Build

Changing how the thing itself works. Its instructions, its scripts, its configuration, its code.

Claude makes a branch, commits, and opens a pull request for you to approve.

The simple test. If Claude has to edit the project's own files, it is Build. If Claude only produces something for you or a customer, it is Work.

Five rules that make it work

These hold whether you work alone or with someone else. Adapt the names, keep the shape.

RULE 1

New task, new chat

One chat does one task. When the task is done, or you want to start something different, open a new window. Never bolt a second task onto an old conversation.

RULE 2

Open every chat with mode, thing, task

State which mode you are in, what you are working on, and what you want. Claude finds the right files itself, and asks rather than guessing if it cannot.

Work: pricing page. Draft the copy for the new tier. Build: pricing page. Add a rule about how discounts display.

RULE 3

Claude handles the branch, you read the summary

In a Build session, Claude creates the branch, commits, and opens the pull request. It writes that pull request in plain English: what changed, and what will behave differently afterwards. You read that summary, never the code, and approve if it matches what you asked for.

Good pull request summary: "The contact form will now send a confirmation email. Previously it sent nothing."

RULE 4

Park improvement ideas, do not act on them mid-task

You will constantly notice things while working. Do not fix them in the same chat. Ask Claude to add the idea to a backlog and carry on. Improving the thing becomes its own Build session later.

Add to the build backlog: the form should resize uploaded photos automatically.

RULE 5

Let lessons become rules only once they repeat

When you give feedback on a draft, it does two jobs. Claude fixes the draft immediately. If the feedback sounds like a standing preference, for example "always shorter headlines", Claude parks it rather than rewriting the instructions on the spot. One piece of feedback is a reaction. The same lesson parked twice is a rule.

Build: pricing page. Apply parked lessons.

Two things to settle before you start

These are decisions, not rules. Make them deliberately.

Find out what merging actually does

Ask Claude what happens when your project's main version updates. Sometimes nothing, and it simply saves. Sometimes it publishes a live website. You need to know which before you press merge for the first time. The stakes should set the care you take, not the other way round.

Decide how carefully to review

Working alone, read the plain-English summary, check it says what you asked for, and merge. That is enough for most changes. Slow down for anything that can escape the building: anything touching money, and anything that sends something outward without a person pressing send. If someone else works on the project with you, those are the changes worth a second pair of eyes.

The reassurance. Everything is reversible. If a merge turns out wrong, ask Claude to take it back out. Review carefully, but do not agonise.

Cheat sheet

The whole system, in four lines.

Work: <thing>. <the job> Get something produced. Nothing to merge.

Build: <thing>. <the change> Change how it works. Claude opens a pull request.

Add to the build backlog: <idea> Park an improvement for later.

Build: <thing>. Undo the last merge. Reverse a change that went wrong.

Make it automatic

Install the skill, and Claude follows these rules on its own

Everything on this page is available as a Claude skill. Once installed, Claude checks GitHub before it changes anything, keeps Work and Build separate, writes pull requests in plain English, and never presses merge for you. It is free and open source.

Three ways to install it, including one where Claude does it for you. See the Get the skill tab.

Free and open source

Stop remembering the rules. Let Claude follow them.

Everything in this guide is available as a Claude skill. Once installed, Claude checks GitHub before it changes anything, keeps Work and Build separate, writes every pull request in plain English, and never presses merge for you.

Pick your route

Three ways in. The first needs no GitHub visit at all, because Claude fetches it for you.

1. Ask Claude to install it

Easiest

For Claude Code or Cursor. No downloads, no folders.

Paste this into Claude and it will do the rest.

Install the skill from https://github.com/marinaritchieAI/git-for-non-coders
into my personal skills folder.

Clone the repository, copy only the inner git-for-non-coders folder
into ~/.claude/skills/, then delete the clone.

Confirm that SKILL.md sits directly inside
~/.claude/skills/git-for-non-coders/ and not one level deeper.

Start a new session afterwards so Claude picks it up.

2. Run the commands yourself

Claude Code

If you would rather see exactly what happens.

# make the skills folder if it does not exist
mkdir -p ~/.claude/skills

# download the repository into a temporary folder
git clone https://github.com/marinaritchieAI/git-for-non-coders.git /tmp/gfnc

# move just the skill folder into place
cp -r /tmp/gfnc/git-for-non-coders ~/.claude/skills/

# tidy up
rm -rf /tmp/gfnc

Works the same on macOS, Linux, and Windows.

Check it worked. Run the line below. You should see SKILL.md listed. If you see another folder instead, the skill is nested one level too deep, which is the most common mistake.

ls ~/.claude/skills/git-for-non-coders/

Then start a fresh session.

3. Upload the file

Claude web and desktop

No terminal involved.

Download the skill file using the button below.
In Claude, open Customize, then Skills.
Upload the file you just downloaded.

Download git-for-non-coders.skill

Skills require code execution to be turned on in your Claude settings.

What changes once it is installed

You will notice the difference within one session.

It checks before it changes. Claude looks at what already exists on GitHub and pulls the latest first, rather than assuming a fresh start.

It knows when Git is not needed. Producing a draft does not get a branch. Changing how the project works does.

Pull requests you can read. What changed, what will be different, what to check. Never a wall of code.

It never merges for you. Preparing the change is Claude's job. Approving it stays yours.

It stops at secrets. If an API key or password is about to be committed, Claude halts and tells you to rotate it.

It removes the fear. When something breaks, it leads with the fact that every version is saved, then fixes it the gentlest way.

Read it before you install it. That is good practice for any skill, from anyone. The source is short and plain: read SKILL.md on GitHub.

The ideas that cause confusion

Six cards. Learn these and everything else falls into place.

Git is not GitHub

Git is the tool on your computer that records history. GitHub is the website where you store and share it. The tool and the cabinet are different things.

A commit is a snapshot

Each commit saves the project at one moment, with a short message. The history is a chain of snapshots you can return to.

A branch is a safe copy

A branch is a parallel version. You experiment there without touching the trusted version, then fold the work back in.

main is the trusted version

The branch called main is the clean, current version everyone relies on. Keep it working. Do risky work on a branch.

Push up, pull down

Push sends your commits up to GitHub. Pull brings other people's commits down. You move work on purpose.

A Pull Request asks for review

A Pull Request proposes merging your branch and opens a page for others to review first. Alone, you often merge directly.

The terms that matter

Grouped by when you will meet them.

Start here

repository (repo) Your project folder plus its entire history. One project, one repository.

commit A saved snapshot of the project at one moment, with a message describing the change.

branch A parallel version where you work without touching the main version.

main The primary branch. The clean, trusted, current version.

clone Copy a repository from GitHub down to your computer, history and all.

push / pull Push sends your commits up to GitHub. Pull brings other people's changes down.

Working with others

merge Combine the commits from one branch into another, usually a finished branch into main.

pull request (PR) A proposal on GitHub to merge your branch, opened for review and approval first.

fork Your own full copy of someone else's repository, under your account.

conflict When two changes touch the same lines, Git stops and asks you to choose. A safety feature, not a failure.

Undo and safety

discard / restore Throw away changes you have not committed yet, returning a file to its last snapshot.

revert A new commit that undoes an earlier one, while keeping the full history intact.

Good to know

remote / origin The cloud copy your local project is linked to. Origin is the default name for your GitHub copy.

stage Marking which changes go into your next commit.

Try it, one step at a time

A short walkthrough. You will build a small project and back it up, following one instruction at a time. Nothing here touches a real project, so you cannot break anything.

Step 1 of 6

You have the model now

Let Claude do this for you, every time

You just did it by hand so the logic makes sense. In practice you never need to. Install the free skill and Claude checks GitHub before it changes anything, keeps your work safe on a branch, and writes every pull request in plain English.

Three ways in, including one where Claude installs it for you.

Quiz

Five questions. Pick an answer to see whether it is right and why.