The High Council insignia

Start here

GitHub, explained like a colleague would explain it.

Most GitHub tutorials either assume you already know what a commit is, or spend an hour on trivia you'll never use. This one takes about an hour and gets you to the point where you can work on a real project with other people without feeling lost.

Begin the walkthrough First, what even is it?

Git and GitHub are two different things

This trips up almost everyone, and untangling it makes the rest of this site much easier to follow.

Git

A program on your computer. It watches a folder and records snapshots of it over time. It works entirely offline, has nothing to do with any website, and was around for years before GitHub existed.

Think: the track changes feature, but for a whole folder, and much better at it.

Explore →

GitHub

A website that hosts Git folders. It stores a copy of your project in the cloud so you can back it up, share it, and — the real reason it exists — let several people work on the same thing without overwriting each other.

Think: the shared drive, plus a discussion layer wrapped around every change.

Explore →

The one-line version Git saves your work in versions. GitHub puts those versions somewhere other people can reach them.

The mental model that makes everything click

Your project doesn't live in one place — it lives in four, and every Git command you'll learn is just moving changes from one of them to the next. Once you can picture this diagram, the commands stop feeling arbitrary.

Why the staging area exists: it lets you save a tidy snapshot even when your folder is messy. You might have edited six files but only want three of them in this particular save — git add is you choosing which ones.

What the whole thing looks like in practice

Here is a real, complete session: someone fixes a typo on a project and gets it shipped. Don't worry about understanding every line — the point is to see how short it actually is.

a typical five-minute change

$ git switch -c fix-footer-typo
Switched to a new branch 'fix-footer-typo'

# ...you edit footer.html in your normal editor...

$ git add footer.html
$ git commit -m "Fix misspelled company name in footer"
[fix-footer-typo 4a91c2e] Fix misspelled company name in footer
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git push -u origin fix-footer-typo
remote: Create a pull request by visiting:
remote:   https://github.com/acme/site/pull/new/fix-footer-typo

Four commands. You open that link, write a sentence explaining the change, a teammate glances at it, and it's merged. That loop — branch commit push pull request — is what you'll do thousands of times, and it's covered properly in The daily loop.

The path through this site

Four pages, in order. Each one builds on the last, and each ends with a link to the next.

First steps

Installing Git, setting up an account, and creating your first repository — then actually saving and pushing a change to it. Includes the browser-only route if you'd rather not touch a terminal yet.

Explore → 2

The daily loop

Branches, commits, pushes and pull requests — the cycle that makes up 90% of real GitHub use. Plus how to read a diff, write a commit message worth reading, and undo things safely.

Explore → 3

With other people

Issues, code review, forks, and the moment everyone dreads: a merge conflict. What they are, why they happen, and a calm procedure for resolving one.

Explore → 4

Level up

The intermediate features that make GitHub genuinely powerful: Actions and CI, releases, rebasing, the gh command line tool, and recovering from mistakes. Ends with a cheat sheet.

Explore →

A glossary you can come back to

Skim it now, and return whenever a word on another page doesn't land. Nothing here needs memorising.

Repository (repo): A project folder that Git is tracking, together with its entire history. On GitHub, a repo is one page with one URL.
Commit: One saved snapshot, with a message explaining what changed and why. The basic unit of everything.
Branch: A parallel line of commits. Lets you work on something without disturbing the version everyone else is using.
main: The conventional name of the primary branch — the version that's considered current and correct.
Remote: A copy of the repo hosted elsewhere. Yours will almost always be called origin and live on GitHub.
Clone: Downloading a full copy of a repo — code, history, and all — onto your machine.
Push / pull: Sending your commits up to the remote, and fetching other people's commits down.
Pull request (PR): A proposal: "here are my commits, please review them and merge them into main." The heart of collaboration on GitHub.
Merge: Combining one branch's commits into another. Usually the final step of a pull request.
Merge conflict: What happens when two people changed the same lines and Git needs a human to decide which version wins.
Fork: Your own copy of somebody else's repo, under your account, so you can propose changes to a project you can't write to directly.
Issue: A thread for tracking a bug, a task, or an idea. Discussion, not code.
Diff: The rendered before-and-after of a change: red lines removed, green lines added.

Questions people ask before they start

Do I have to use the command line?

No — you can create repositories, edit files, and merge pull requests entirely in the browser, and First steps shows you how. GitHub also publishes a free desktop app with buttons for all of it.

That said, the terminal commands are short, they're identical on every machine you'll ever touch, and every answer you find online will be written in them. This site teaches the commands, and points out the browser equivalent where one exists.

Is GitHub only for programmers?

It's mostly used for code, but the underlying idea — track every version, propose changes, discuss them, merge them — applies to anything stored as text. People run legislation, recipe collections, academic papers, and entire books on it.

The one honest limitation: Git works beautifully with text files and poorly with large binary files like video, big design files, or Word documents. It can store them, but it can't show you what changed inside them.

Is it free? Will my code be public?

Free accounts get unlimited public and private repositories. Nothing is public unless you choose "Public" when you create it, and you can change a repo's visibility later.

One caveat worth internalising early: once something has been pushed to a public repo, treat it as permanently public. Deleting it later doesn't reliably remove it from clones, caches, and forks — which is exactly why you should never commit passwords or API keys. More on that in Level up.

What if I break something?

Almost nothing in Git is truly destructive, because the whole point of the tool is that it remembers. Committed work can be recovered even after a bad merge, a deleted branch, or a reset you regret.

The genuine ways to lose work are narrow and worth knowing: changes you never committed, and force-pushing over a branch someone else was using. Both are covered in Level up.

How long until I'm actually useful on a team?

Honestly? An afternoon to be functional, a couple of weeks to be comfortable. The daily loop is genuinely small — most working developers use maybe eight commands regularly. Everything beyond that is something you look up on the rare day you need it, which is exactly what Level up is for.