GitHub without the fear
Written by a person. Last read by a person on 2026-09-04, 4 days ago. Its facts were checked by the eval suite on 2026-09-07.
You have been asked to make a change in a repository and have never used version control, or you have been using it by copying commands and would like to know what they actually do.
This is for people who have to work with GitHub and do not write code for a living. Designers, writers, researchers, program managers, anyone who has been handed a repository and told it is where the work lives now.
It is not a tutorial. Tutorials teach you which buttons to press, and you can follow one to the end and still be frightened, because you did the steps without ever being told what they meant. The fear does not come from not knowing the commands. It comes from not having a model of what is happening, so every action feels like it might break something invisible and permanent.
This page gives you the model first. The mechanics come after, and they are short, because once the model is right the mechanics are mostly obvious.
Where these commands go
This page shows lines like git commit. They are typed into a terminal, which is a window
where you type a command, press Enter, and read what comes back.
On a Mac it is the Terminal app. On Windows it is Git Bash, installed with git. Your editor probably has one built in, often at the bottom of the window.
Two things worth knowing before you open one.
It is a conversation, not a form. You type one line, press Enter, and it answers. Nothing happens until you press Enter, so a half-typed command is not a half-done action.
Nothing here runs on its own. Every command on these pages does one thing when you run it and nothing at any other time. There is no state you can leave a command in.
If a command prints something you were not expecting, that is the terminal telling you what it did, and it is usually the most useful thing on the screen. When something looks broken reads the common ones.
Start with two places
Here is the model most people arrive with, and it is not wrong. It is just missing things.
flowchart LR A["Your computer"] --> D["GitHub"]
Your work is on your computer. At some point it goes to GitHub, where other people can see it. Everything else this page adds is detail inside those two boxes.
If that were the whole story, there would be one verb: send. There are three, and the next two sections are about why.
Three places, not one
The left box is really three, and moving between them is always something you do deliberately.
flowchart LR A["Your files<br/>(the working copy)"] -->|git add| B["The staging area<br/>(what goes in next)"] B -->|git commit| C["Your history<br/>(local repository)"] C -->|git push| D["GitHub<br/>(the remote)"]
In words, because a diagram you cannot read is not an explanation:
- Your files. The documents on your computer, as your editor sees them. Saving in your editor changes these and nothing else.
- The staging area. A holding pen for the changes you have decided belong together in the next entry in the history. Nothing is recorded yet.
- Your history. A permanent, ordered record of entries, living on your computer.
- GitHub. A copy of that history on a server, which is the only place other people can see it.
Work moves between these one step at a time, and only when you say so. Nothing travels on its own.
The arrow that goes the other way
Everything so far points right, which is true only while you are the only person working. The moment somebody else pushes, GitHub holds work your computer has never seen.
flowchart LR A["Your files<br/>(the working copy)"] -->|git add| B["The staging area<br/>(what goes in next)"] B -->|git commit| C["Your history<br/>(local repository)"] C -->|git push| D["GitHub<br/>(the remote)"] D -->|git pull| C
git pull is that arrow. It is not a download of the current files; it brings the entries you
are missing into your history, and then updates your files to match.
This is why "it works on my machine" happens to people who have never written a line of code. Your files are not the shared truth. They are your copy of it, as of the last time you pulled.
This is why so much of git feels like ceremony. It is not ceremony. Each step is a place where you get to decide what is included and what is not, and the reason there are several is that they answer different questions.
Why "save" is three verbs here
In every other program you have used, save means one thing. Here it means three, and they happen at different times for different reasons.
| What you do | What it changes | Who can see it |
|---|---|---|
| Save in your editor | The file on your disk | You |
git add, then git commit |
Your local history | You |
git push |
The copy on GitHub | Everyone with access |
The consequence worth memorising: committing does not publish anything. You can commit twenty times over three days and nobody will know until you push. Many people discover this the other way round, by assuming they had shared work that was sitting on their laptop the whole time.
History is not an undo stack
This is the one that causes real distress, so it is worth being blunt about.
If you expect history to be a stack of undos — press the button, go back one step, press again, go back further — then git's history will behave in ways that seem malicious. It is not a stack. It is a record of states you decided were worth keeping, each with a note about why.
That distinction has a practical consequence you will feel immediately: going "back" is not one operation. It depends on what you actually want.
- Undo the edits I have not committed yet, and return to my last commit.
- Keep the history but add a new commit that reverses an earlier one.
- Rewrite the history so an earlier commit is no longer in it.
These are different actions with different risks, and lumping them together as "undo" is what makes them frightening. The third one is the only genuinely dangerous one, and it is the one you will almost never need. When something looks broken takes each of these separately.
Wrong models people arrive with
If one of these is the model you have, it is worth reading the correction rather than skipping ahead. A wrong model does not announce itself; it just makes everything slightly confusing until one day it makes something go badly wrong.
"It's Dropbox for code"
What you expect. You save a file, and it syncs. Everyone sees the current version. If two people edit at once, something sensible happens automatically.
What actually happens. Nothing syncs. Nothing leaves your computer until you push, and nothing arrives from anyone else until you pull. There is no background process keeping you current.
What breaks. You work for a week believing your team can see your progress. They cannot. Or you edit a file that someone else changed three days ago, and when you finally pull, git asks you to decide which version wins — a question Dropbox would have answered silently and probably wrong.
The correction is not "git is worse at syncing". It is that git is not a syncing tool at all. It is a tool for recording decisions, and the recording is manual because the decisions are yours.
"Commit means save"
What you expect. Commit is the save button. You press it so you do not lose work.
What actually happens. Your work is already safe on disk the moment your editor saves. A commit does something else: it adds an entry to a permanent record, with a message explaining why the change was made.
What breaks. People who believe commit means save produce histories that read update,
update2, fixes, more fixes. Every entry is a save point and none of them says anything. Then
six months later somebody needs to know why a line changed, and the record that exists to answer
that question does not.
Commit when you have finished a thought, not when you are afraid of losing one.
"The website is the project"
What you expect. github.com is where the project lives. The files on your computer are a copy you downloaded.
What actually happens. It is the other way round, or rather there is no "round". Every clone is a complete repository with the entire history. GitHub's copy is not more real than yours; it is just the one everyone has agreed to meet at.
What breaks. This model makes people afraid to work locally, because it feels like being away from the real thing. It also makes the reverse mistake possible: treating a change made in the GitHub web editor as somehow not counting, when it is a commit like any other and your local copy now does not have it.
What is stable here, and what is not
The three-places model, the three meanings of save, and the nature of history do not change. They have been true for the entire life of git and they will still be true when the screenshots in every other guide have rotted.
What does change is the interface: the wording on buttons, where a menu sits, what a screen is called. This runbook teaches the model and the commands instead, deliberately. The model is what transfers; the appearance is what goes stale.
Where you need the exact clicks for today's interface, GitHub's own documentation is the right source. It is kept current in a way a third-party guide cannot be.
That is a deliberate choice about what to promise, not an omission.