GitHub, in depth
GitHub hosts Git repositories, but that's the least interesting thing about it. Almost everything you think of as "using GitHub" is a layer invented on top of Git — and knowing which is which tells you what travels with you if you ever leave.
1 · What it is, and who owns it
GitHub launched in 2008. Git existed and worked, but setting up somewhere to put a repository meant renting a server and configuring it yourself, and there was no good way to discuss a change other than emailing patches to a mailing list. GitHub made hosting a repository take about four seconds, and wrapped a conversation around every change.
That combination — free hosting plus a social layer — is why it became the default. Not because it's the only option, and not because Git requires it.
Microsoft acquired GitHub in 2018 for around $7.5 billion in stock. It continues to run as its own product.
Worth holding onto: GitHub is a commercial company running a website. Git is free software owned by nobody. They're often spoken about as one thing, and the difference matters most on the day you'd rather not depend on a company.
2 · What GitHub adds that Git doesn't have
Nearly everything you interact with on the site is GitHub's invention. Git has none of it.
| Feature | Whose? | What it does |
|---|---|---|
| Commits, branches, merges, tags | Git | The version control itself. Works offline, works anywhere. |
| Pull requests | GitHub | A proposal with a diff, a discussion, and a merge button |
| Issues | GitHub | Threads for bugs, tasks, and ideas |
| Code review | GitHub | Line-level comments, approvals, requested changes |
| Actions / CI | GitHub | Running your tests on their machines when something happens |
| Forks | GitHub | A server-side copy under your account. Git just has clones. |
| Stars, followers, profiles | GitHub | The social layer |
| Permissions, teams, protected branches | GitHub | Who may do what. Git has no concept of a user account at all. |
| Releases | GitHub | Notes and downloadable files attached to a Git tag |
Read that column and the shape becomes clear: Git manages versions; GitHub manages people. Permissions, review, discussion, notifications, automation — all the coordination problems that appear the moment more than one person is involved.
3 · The pull request is not a Git feature
This one is worth its own section, because it's the most common misconception among people who've used GitHub for years.
There is no git pull-request command. You cannot open a pull request against a repository sitting on a USB stick. A pull request is a record in GitHub's database that says: here are two branches, show me the difference, let people comment on it, and give an authorised person a button that merges one into the other.
The merge it eventually performs is an ordinary Git merge. Everything around it — the diff view, the conversation, the approvals, the checks, the button — is GitHub's.
Where the name comes from. Before hosting platforms, you'd email a maintainer asking them to pull your changes from your publicly readable repository. Git still ships git request-pull, which generates the summary text for exactly that email. GitHub took the concept and made it a web page.
The practical upshot: your commits are portable and your pull request discussions are not. That's covered below.
4 · What happens when GitHub is down
It does happen, and the answer is reassuring: most of your work carries on. Because Git is distributed, your clone is complete.
Still works
- Committing, branching, merging
- Reading the entire history
- Checking out any past version
- Resolving conflicts
- Recovering lost work with
reflog
Stops
- Pushing and pulling
- Pull requests and reviews
- Issues
- Actions and CI
- Anything that deploys from a push
So an outage is a collaboration outage, not a work outage. Keep committing locally and push when it returns.
5 · The alternatives
GitHub is the largest, not the only. Everything in this guide's daily loop transfers to any of these, because the Git part is identical — only the website around it differs.
Learning GitHub is not a lock-in. The commands are the same everywhere; what changes is where the merge button lives.
6 · How portable your work really is
Worth knowing before a project matters to you.
| What | Portable? | Why |
|---|---|---|
| Your code and its full history | Completely | Every clone already contains it. Push it somewhere else and you've moved. |
| Tags and releases (the tags) | Yes | Tags are Git objects. The release notes and attached files are GitHub's. |
| Issues and pull request discussions | Only via export | They live in GitHub's database, not your repository. Retrievable through the API or a migration tool, but they don't come with a git clone. |
| Actions workflows | Files yes, behaviour no | The YAML is in your repo, but it's written against GitHub's runners and syntax. Another platform needs it rewritten. |
| Stars, forks, followers | No | Purely GitHub's social graph. |
The reassuring half: the part that matters most — the code and every version of it — is the part that's most portable. It's already on your laptop, in an open format, and moving it is one git push to a different address.
The part to be deliberate about: if years of design discussion accumulate in issues and pull requests, that context lives on someone else's servers. For a project you'd be genuinely upset to lose, it's worth periodically exporting — or keeping the decisions that really matter in a file inside the repository, where they travel with the code.