Interactive Explainer
GitHub is the New Google Drive
7 concepts, 1 workflow. Everything a non-engineer needs to collaborate like a pro.
Based on Tool School: GitHub 101 by Hannah Stulberg & Sidwyn Koh
01
Why It Matters
You don't need to write code to benefit from GitHub. You need to understand the system your team already runs on.
Your work has a safety net
Every change is tracked and reversible. You'll never lose work or wonder "who changed this?" again.
Collaborate without chaos
Multiple people edit the same project simultaneously. No more "Final_v3_REAL_final.docx" file names.
AI tools need it
Claude Code, GitHub Copilot, and other AI coding tools work directly with repositories. 92% of Fortune 100 companies now use GitHub.
It's a career multiplier
GitHub literacy is increasingly expected across product, design, data, and ops roles. Not just engineering.
This isn't about becoming an engineer. It's about understanding the tool your team already uses every day — the same way you learned Figma or Google Analytics.
02
The Rosetta Stone
Every GitHub concept has a Google Drive equivalent you already understand. Match them below.
| GitHub Term | Google Drive Equivalent | What It Actually Does |
|---|---|---|
| Repository | Shared folder | A project folder that tracks every change ever made |
| Branch | Making a copy to edit safely | A parallel version where you make changes without affecting the original |
| Commit | Saving with a note | A snapshot of your changes with a message explaining what you did |
| Push | Uploading your changes | Sends your commits from your computer to GitHub |
| Pull | Downloading the latest | Gets the newest changes from GitHub to your computer |
| Pull Request | Asking for a review | A proposal to merge your branch's changes into the main branch |
| Merge | Accepting changes | Combines a branch's changes into the main branch |
03
Branches
A branch is a parallel version of your project. You make changes on your branch without affecting anyone else's work. When you're done, you merge back.
Think of it like making a photocopy of a shared document. You mark it up freely, and when your edits are approved, someone incorporates them back into the original. Except Git does this automatically.
main — 2 commits
Never commit directly to main in a shared repository. Always create a branch first. The main branch is the "official" version — treat it like a published document.
04
Commits
A commit is a save point with context. It records what changed and why — so anyone (including future you) can understand the project's history.
The difference between a good and bad commit message is the difference between "changes" and "Add Q2 catering vendor contacts and remove expired entries." One is useless. The other tells a story.
When to commit
- After completing a logical unit of work
- Before switching to a different task
- When you want a checkpoint you might need to return to
- After fixing a bug
- Before trying something experimental
Commit often, push regularly. Small, frequent commits are easier to review, easier to revert, and easier to understand than one massive change at the end of the day.
05
The Daily Workflow
Seven steps. Always the same order. Once you've done it three times, it becomes muscle memory.
06
Pull Requests
A pull request is a formal proposal to merge your changes. It's where collaboration actually happens — not in the code itself, but in the conversation around it.
Code Review
Team members review your changes line by line before they go live. Catches bugs, typos, and logic errors before they reach production.
Discussion
Comment on specific lines, ask questions, suggest improvements. The conversation is preserved forever — future team members can read it.
Quality Gate
Automated checks run tests on your changes. If something breaks, you'll know before it's merged — not after it's live.
Paper Trail
Every change has a documented reason, an author, and an approver. Auditing, onboarding, and debugging all become easier.
A good PR description answers three questions: What changed? Why? How can someone test it?
You don't need to understand every line of code in a PR. Focus on the description, the files changed, and whether the approach makes sense. That's already a valuable review.
07
When Things Go Wrong
Mistakes are normal. The good news: Git was designed to recover from them. Test your instincts before we reveal the full guide.
✓ You're ready. Here's the full error guide.
| Situation | What Happened | What to Do |
|---|---|---|
| File disappeared after switching branches | Files live on branches — your file is on your branch | Switch back to your branch |
| Merge conflict | Two people edited the same line | Choose which version to keep in the editor |
| Committed a secret | Sensitive data is now in Git history | Remove from history with BFG or git filter-repo, then rotate your keys immediately |
| Pushed to wrong branch | Changes went to main or wrong branch | Revert the commit, push your changes to the correct branch |
| Lost uncommitted work | Changes were discarded before committing | Check git stash list or git reflog — Git often saves more than you think |
You Now Speak GitHub
You've learned the 7 concepts and the workflow that every team uses daily. That's the whole system.
- 7 concepts from repository to merge
- 1 workflow you'll use every day
- The confidence to collaborate with any engineering team