GitHub for people who do not write the code

If you have never used GitHub, ignore how it is usually described. It is not a social network for programmers, you are not there to read anyone else’s code, and the green squares are not a scoreboard you have to fill.

It is a save system with a history, hosted somewhere that is not your laptop. That is the whole thing.

For a vibe coder it earns its place for one specific reason. At some point — not maybe, at some point — a session will rewrite something that already worked. It will refactor a file you liked, delete a function it decided was unused, or fix one bug by quietly introducing two. Without commits, that work is gone and your only recovery is describing it again from memory to a model that has forgotten the conversation. With commits, recovery is one sentence.

This guide is everything you need for that, and nothing you do not.

Git and GitHub are not the same thing

Worth ten seconds, because conflating them is what makes the rest confusing.

Git is a program on your computer. It records versions of a folder. It works with no internet, no account and no website, and it is what does all the actual work.

GitHub is a website that holds a copy of a Git repository, and adds the things a website can add: a page to browse it, a place for other people, automation that runs when you push.

So when your agent “commits”, that is Git, locally, instantly. When it “pushes”, that is the copy travelling to GitHub. This is why you can work on a plane and why a commit is not a backup until it has been pushed.

The alternatives — GitLab, Bitbucket, Codeberg — are the same Git underneath with a different website on top. Nothing in this guide changes if you pick one of those.

The seven words that cover almost everything

Two more you will see and can mostly ignore: origin is the default nickname for “the copy on GitHub”, and main is the default name of the primary branch.

Do I need to learn Git commands?

No, and this is the part nobody tells beginners. You need three sentences to say to your agent, and it runs the commands.

• Commit this with a clear message.
• What has changed since the last commit?
• Undo everything since the last commit.

That is the entire interface for your first month. What you do need is to understand what those three things mean, which is what the rest of this page is for — because the failure mode is not typing the wrong command, it is asking for the wrong kind of undo.

If you would rather have buttons than sentences, GitHub Desktop is free, shows changed files as a visual diff, and turns commit and push into two clicks. Many people who ship real products never use the terminal for Git at all.

Where your code lives while you are working

Git messages talk about files being “staged”, “tracked” and “untracked”, and none of it makes sense until you know there are three places a change can be:

The staging area is the part that feels pointless at first. Its purpose is choosing: twelve files changed, four of them belong to this commit, so you stage those four. As a vibe coder you will mostly commit everything at once — but you need to know staging exists, because “changes not staged for commit” is otherwise an error message about nothing.

git status is the “where am I” command, and it is the one worth being able to read yourself. It tells you which branch you are on, what is changed, what is staged, and whether you are ahead of or behind GitHub. When something is confusing, this is the first thing to look at, and it is completely safe — it changes nothing.

The first file that matters: .gitignore

Before your first push, before anything else: .gitignore is a list of files Git must never record.

At minimum it contains:

.env
.env.local
node_modules/
.DS_Store
dist/

.env is the one that matters. That is where your API keys live, and that one line is what stops them from being published the first time you push. Public repositories are scanned continuously by people looking for exactly this, and a leaked key is found in minutes, not days.

Ask for it explicitly at setup — add a .gitignore appropriate for this stack, and make sure .env is in it — and then check with your own eyes that .env is listed. This is a thirty-second check that prevents the single most common expensive beginner mistake.

Make the repository private by default. Public is a deliberate decision to publish, and it is far easier to make a private repository public later than to un-publish something — including everything in its history.

How do I read a diff without reading code?

A diff is what changed, shown line by line. Green lines with + were added, red lines with - were removed, grey lines are unchanged context. You do not need to understand the code to get real value from it:

• How big is it? Twelve lines changed for a small ask is normal. Four hundred is a signal to stop and ask what else it did.
• Which files? If you asked for a colour change and a file with auth or migration or schema in the name is in the list, that is the moment to ask why.
• Anything deleted that you did not ask to delete? Long blocks of red are worth a question.

That is the whole skill, and it is most of what code review gives you on a solo project. Show me the diff, and explain in plain English what each file’s change does is a good habit before every commit.

What makes a commit message worth writing?

Its only job is to help future-you find a moment in time. “Update” and “fixes” fail at that; six of them in a row are indistinguishable.

Write what the state is, not what you did: login screen works, validation not done yet. Six weeks later, that message is what lets you say “go back to when login worked” and mean something precise.

Commit when something works, not at the end of the day. The end of the day is one save point for eight hours of decisions. Every working state is a place you can return to.

When do I actually need a branch?

As a solo vibe coder, less often than tutorials imply. You need one when you are about to try something you might regret — a big refactor, a risky dependency swap, an experiment you are only half sold on.

The reason is that the undo becomes free. You are on experiment, it goes badly, you switch back to main and delete the branch. Nothing to unpick, nothing to revert, no argument with the agent about what it changed.

The moment anyone else touches the repository, this stops being optional and becomes one branch per piece of work — which is where vibe coding gets genuinely harder, and a different problem from this one.

How do I undo something?

The most important section on this page. There are four kinds of undo and asking for the wrong one is how people lose work while trying to save it.

1. You have changes you have not committed, and you want them gone.

git restore .

Everything since the last commit disappears. This is the everyday one — the session went wrong, nothing was worth keeping, start again from the last good state.

2. You committed, but have not pushed, and want the commit gone.

git reset --soft HEAD~1   # undo the commit, keep the changes
git reset --hard HEAD~1   # undo the commit and the changes

--soft is for “right commit, wrong message, wrong moment”. --hard is for “that whole direction was wrong”.

3. You already pushed, and other people (or a deployment) have it.

git revert <commit>

This makes a new commit that undoes the old one. It is the safe one, because it adds to history rather than rewriting it, and nothing anyone else has ever disagrees with what you have.

4. You think you have lost something permanently.

git reflog

Git keeps a private log of every position your branch has been in for around ninety days, including commits you “deleted” and branches you removed. Almost nothing is ever actually gone. This is the one to reach for after a --hard you regret or a force-push that ate your afternoon — and it is worth knowing it exists precisely because the moment you need it is the moment you are panicking.

What is a merge conflict, and who fixes it?

Two branches changed the same lines. Git will not guess which version wins, so it marks the disputed section in the file with <<<<<<< and >>>>>>> and stops.

Nothing is broken and nothing is lost. Both versions are right there; something has to choose.

Agents are good at this, on one condition: tell them what each change was for. The decision is about intent, not syntax — this side is the new pricing logic, that side is the bug fix from yesterday, keep both behaviours gets a correct resolution. “Fix the conflict” gets a coin toss.

What happens if I commit an API key?

Rotate it. Now. Go to the service, revoke the key, issue a new one.

Deleting the file in a later commit does nothing, because the key is still sitting in the history where anyone can read it. On a public repository, assume it was scraped within minutes — this is automated at scale.

GitHub helps at two points, and both are worth turning on. Secret scanning notices known key formats in your repository and alerts you. Push protection goes further and blocks the push before the secret ever lands. Neither covers every format, so .gitignore remains the actual defence.

Cleaning the key out of history afterwards is possible and fiddly. It is also secondary: once the key is rotated, the one in the history is a dead string.

What else is GitHub, beyond storage?

Things you will meet, in one line each:

• Issues — a to-do list attached to the project. Fine for solo notes, though a real board is better once work has shape.
• Actions — automation that runs on push. This is how tests run and how deploys trigger. You will meet it the first time you connect a host.
• Releases and tags — a name pinned to a specific commit. v1-launch is a bookmark saying this version was good, and it costs nothing.
• Pages — free static hosting straight from a repository. Fine for a landing page, not for anything with a backend.
• Fork — your own copy of somebody else’s repository. Relevant when you want to change someone’s open source project.
• Dependabot — opens pull requests when a dependency has a security fix. Free, worth leaving on.
• Codespaces — a full dev environment in the browser. Useful when you want to work from a machine that has nothing installed.

Things that will confuse you exactly once

Each of these produces a moment of genuine alarm, and each is harmless once you have seen it.

“You are in ‘detached HEAD’ state.” You looked at an old commit and are now standing on it rather than on a branch. Commits made here belong to nothing and are easy to lose. git switch main walks back. Nothing is broken.

Your repository contains another repository. An agent ran git init inside a folder that was already in a repo, usually while scaffolding something. GitHub then shows a folder you cannot open, containing nothing. The fix is deleting the inner .git folder — and the tell is a commit that adds a directory but none of the files in it.

A file is too large to push. GitHub rejects individual files over 100MB, and a video, a database dump or a node_modules that escaped .gitignore will hit it. The trap is that removing the file does not fix the push, because it is still in the history — the commit that added it has to be undone. Much easier to prevent: check .gitignore before the first push.

Your two machines disagree. You committed on the laptop, pushed, then committed on the desktop without pulling. Git will refuse the second push. git pull first, resolve anything it asks about, then push. The habit that avoids it entirely is pulling at the start of a session rather than at the end.

The agent committed as somebody else. Commits carry the name and email in your local Git config, which on a fresh machine may be blank or wrong. Worth setting once, or your history is authored by “unknown”.

Hacks that pay for themselves

• Commit before every agent session, not after. The commit is not a record of what you did, it is the save point you are about to risk. Ten seconds, and it converts every disaster into git restore .
• Ask for the diff before you accept. Show me what you changed and why catches the helpful extra thing you did not want, which is the most common failure that survives to production.
• One branch per experiment, and delete is the undo. Cheaper than any revert.
• git stash when the agent complains about a dirty tree. It pockets your uncommitted work; git stash pop gives it back. Better than committing junk to get unstuck.
• --force-with-lease, never plain --force. Both rewrite what is on GitHub. The first refuses if someone else pushed in the meantime; the second overwrites them without asking.
• Protect main once anything real is on it. GitHub’s branch protection can require a pull request before merging, which makes “the agent pushed straight to main at 2am” structurally impossible rather than merely discouraged.
• Tag the version that worked. Before a big change, v-works costs nothing and is trivially findable, unlike a commit hash you will never recognise.
• Squash when you merge. Fourteen commits of “wip”, “fix”, “actually fix” collapse into one meaningful entry, and your history stays readable by a human — and by the next agent that reads it.
• Remember reflog exists before you need it. The moment you need it, you will not be in a state to discover it.

What to do on day one

1. Create the account. Make the first repository private.
2. Get .gitignore in place with .env in it, and check with your own eyes.
3. Ask the agent to make the first commit and push it. Look at the repository on GitHub and see your files there.
4. Then, every time something works: commit this with a clear message.

That is the whole practice. Everything else on this page is there for the day something goes wrong — and the reason to read it now is that the day something goes wrong is a bad day to be learning which kind of undo you need.

The rest of the setup this fits into — the model, the host, the stack, the guardrails — is six decisions long, and version control is the one that everything else assumes you already have.