GitHub cheat sheet: everything from the video on one page
The quick-reference version of "GitHub Explained... Like I'm Five." Git vs GitHub, repos, commits and hashes, pushing, undoing a mistake, branches and pull requests.
Just watched GitHub Explained... Like I'm Five? Here's the whole thing on one page.
The big idea
Ever had a folder full of files called final, final_v2 and final_v2_REALLY_final? Programmers had that problem too, except their files run websites, apps and sometimes airplanes. So they built something better.
First things first: Git and GitHub are not the same thing.
| Git | GitHub | |
|---|---|---|
| What it is | A tool | A website |
| Where it lives | On your computer | On the internet |
| Video game version | Save points. Reach a good spot, save. Mess up later, load an earlier save and try again. | Your saves in the cloud. Like Google Drive or iCloud, but for your code and its entire history. |
Git makes the saves. GitHub keeps them safe and lets you share them.
Words you'll hear a lot
| Word | What it means |
|---|---|
| Repository ("repo") | A fancy word for a place to store stuff. Your code lives in one. |
| Commit | A save point. |
| Commit message | The short note on each commit saying what changed, like "Add homepage." |
| Commit hash | Every commit's unique ID, like a fingerprint. No two commits share one. It's a long string of letters and numbers, usually shown shortened to something like 3f9a2c1. |
| Push | Sending your new commits from your computer up to GitHub. |
| Clone | Copying a repo from GitHub down to your computer, history and all. |
| Revert | Undoing a commit by adding a brand-new commit that reverses it. |
| Branch | A separate line of save points, so you can try changes without touching the main one. |
| Pull request | A request to bring the changes from one branch into another. |
| Merge | Actually combining those changes into the other branch. |
| IDE | The app programmers write code in. Basically a fancy text editor. Visual Studio Code (VS Code) is a free one. |
| Pipeline | A series of steps that run automatically, like grabbing your latest commit and updating your website. |
Commits happen on your own computer. Nothing reaches GitHub until you push.
Why GitHub?
There are plenty of ways to send files to people. Here's what GitHub adds:
- Everyone sees the whole history. Every save, who made it and why. If something breaks while you're on vacation, your coworkers can find the change that caused it without digging through folders, or calling you at the beach.
- Work from anywhere. Your code and every save point are online, whether you're at work or on vacation.
- Other computers can use it too. They can grab your code from GitHub and run it. Pipelines can pull your latest save and update your website or app automatically.
Henry builds his first website
- Make a repo. Henry signs up for a free account at GitHub.com and creates a repo called
henrys-website. - Get set up. He installs VS Code (to write code) and Git (to make save points), signs in to GitHub, and clones his repo down to his computer.
- Save and send. He writes a basic homepage, makes his first commit with the message "Add homepage," and pushes it to GitHub.
- Make it a real website. He turns on GitHub Pages, GitHub's free web hosting (free for public repos). Now every time Henry pushes a new commit, his website updates by itself.
This is just one way to set it up. GitHub has competitors like GitLab, other hosting services like Cloudflare can connect to GitHub and deploy your code automatically, and companies often build custom pipelines. For today, we're sticking with the basics.
Oops: undoing a mistake
A week later, Henry adds a picture of himself, commits, pushes, and... the whole page is blank!
No problem. Henry looks through his history, finds the commit that broke things, and reverts it. Then he pushes again, GitHub Pages picks it up, and his website is back.
Git doesn't erase the mistake. A revert adds a brand-new commit that undoes it, so you can always look back and see what went wrong and when.
Branches and pull requests
So far Henry has only had one branch, main, so every push goes straight to his website. To avoid another blank page, he makes a development branch.
Think of it like video game profiles. Henry's brother Hunter wants to play Henry's game, starting from Henry's last save point. Henry doesn't want Hunter messing with his saves, so they make Hunter his own profile.
| In the game | In Git |
|---|---|
| Henry's profile | The main branch (the live website) |
| Hunter's new profile | The development branch (try things out safely) |
Henry now pushes his changes to the development branch, and his website doesn't change. When he's happy with them, he opens a pull request to bring those changes into main, then merges it. That updates his website.
Unlike a video game, Git can combine the two profiles later. That's what pull requests are for. (Strictly speaking, Git does the merging, and a pull request is GitHub's way of asking for it, so people can look over the changes first.)
Quick recap
- Git makes save points on your computer. Those saves are commits, and each one has a fingerprint called a hash.
- You push commits up to GitHub, which shares them with everyone working on the code, lets you work from anywhere, and lets other computers run your code.
- You can test changes on a branch and bring them into main with a pull request.
There's a lot more to GitHub, like rulesets to protect your branches, forks and GitHub Actions; this is just the basics. What other tech topics should we explain like you're five? Let us know in the YouTube comments!