Every GitHub tutorial assumes you already know where Git ends and GitHub begins. Most working developers I have met, including the one writing this, spent their early years fuzzy on exactly that line. The fuzziness is not embarrassing; it is the natural result of learning the two together. But it causes real mistakes, so this course starts by drawing the line properly.
Two things with confusingly similar names
Git is a program. It runs on your machine, was released in 2005, and is, in its own words, a free and open source distributed version control system. It needs no account, no internet connection, and no company. You can use Git for a decade without ever touching a hosting service: git init in a directory and you have a complete, working version control system in a hidden .git folder.
GitHub is a company, and a hosting platform that company runs. It stores copies of Git repositories on its servers and layers a workflow product over them: pull requests, issues, Actions, code review, access control. When you git push, you are using Git the program to send commits to GitHub the service. The two are separable at every level: the same Git can push to GitLab, Bitbucket, a bare repo on your own server, or a second directory on the same laptop.
The naming did the damage. GitHub sounds like "the place Git lives", and for many teams it effectively is, which is how the two blur into one concept. They are one concept in the way that "email" and "Gmail" are.
The four-places model
Here is the frame the rest of this course leans on. Your work exists in up to four places, and every Git command is a movement between them:
The line between Git and GitHub runs between the third and fourth box. Everything above it works on a plane with no wifi. The consequences are practical, not academic:
- A commit is not a backup. Committing puts work in your local repository. If the laptop dies before you push, the commit dies with it. This course's system-of-record chapter builds on exactly this point: work is durable when it reaches the remote, not when it is committed.
- Deleting the GitHub repo does not delete the project. Every clone is a full copy of the entire history. That is what "distributed" means in Git's self-description: there is no single privileged copy, only the copy everyone agrees to treat as canonical.
- GitHub being down does not stop you working. Commits, branches, diffs, history: all local. Only push, pull, PRs and Actions wait for the service to come back.
What belongs to which
When something goes wrong, knowing which product owns the behaviour tells you where to look:
| Behaviour | Owned by |
|---|---|
| commits, branches, merges, history, tags | Git |
the staging area and .git directory | Git |
| hooks that run on your machine | Git |
| pull requests, reviews, issues | GitHub |
| Actions, runners, the minutes bill | GitHub |
| access control, private/public, tokens and scopes | GitHub |
A merge conflict is a Git problem; the docs that help are git-scm.com. A blocked push over token scopes is a GitHub problem; the fix is gh auth, covered in the CLI chapter. Half of effective troubleshooting is aiming at the right manual.
Why this course is called what it is called
This course teaches GitHub as the operating system of shipping: the remote as the system of record, PRs as the unit of change, Actions as the enforcement and delivery layer. But every one of those chapters stands on Git fundamentals, and when the two blur, people attribute Git's behaviour to GitHub and vice versa. The squash-merge chapter is a perfect example: the confusing part of squash merging is pure Git (what a local branch believes after the remote squashed it), triggered by a button that is pure GitHub.
Keep the four-places model loaded. When any later chapter says "local", it means boxes one to three. When it says "the remote", it means the box that survives your laptop.
Prove the separation
Demonstrate to yourself that Git works with no GitHub involved, then connect the two explicitly.
Expected behaviour
- A new directory initialised with git init, with one file committed, entirely offline
- git log showing your commit exists with no remote configured
- git remote -v printing nothing, then printing an origin after you add one
PROVE IT git log --oneline && git remote -v
Your laptop dies an hour after you committed important work. You never pushed. What survives?
Which command moves work from the staging area to the local repository?
A colleague says they cannot work because GitHub is down. Using the four-places model, what can they actually still do, and what genuinely has to wait?
Show answer
Everything in the first three places still works: editing in the working directory, staging, committing, branching, merging, viewing history and diffs, all of it local. What waits is anything that crosses to the fourth box or uses GitHub's product layer: push and pull, opening or merging PRs, code review, and any Actions runs, including deploys. So they can keep building and committing locally and push the accumulated commits when the service returns.