Git & GitHub — Save Your Work Like a Pro
What you'll learn
- Why every developer on Earth uses Git
- The 5 commands you'll type every single day
.gitignore— keeping secrets and junk out of your history- What GitHub is (and how it gets you hired)
- A simulated coding exercise modeling how commit history works
This lesson is mostly theory + quiz — Git itself runs in your computer's terminal, so we'll prepare you to use it there, plus one browser exercise that models the core idea.
The magic photo album 📸
Imagine writing a school essay. You save it as essay.doc, then essay-final.doc, then essay-final-FINAL-2.doc… chaos, right?
Git is a magic photo album for your code. Whenever you finish a piece of work, you take a snapshot (called a commit). The album remembers every snapshot forever:
- You can look at any old snapshot
- You can go back in time if you break something
- You can see exactly what changed between snapshots and who changed it
GitHub is the online copy of your album. It means: your work is safe if your laptop dies, teammates can work with you, and — this matters for your career — employers look at your GitHub like a portfolio.
These 5 commands are 90% of daily Git. Read them top to bottom — this is the exact rhythm of a working developer's day: change code → status → add → commit → push. (These run in your computer's terminal, not in the browser.)
# start the album in your project folder (once per project)
git init
# see what changed since the last snapshot
git status
# choose which changes go in the next snapshot
git add .
# take the snapshot, with a note describing it
git commit -m "Add login page"
# upload your album to GitHub
git pushBranches — parallel universes 🌿
One more superpower: a branch is a parallel copy of your project where you can experiment safely. The main universe is called main.
git checkout -b new-feature # create + enter a parallel universe
# ...work, commit, work, commit...
git checkout main # back to the main universe
git merge new-feature # bring your experiment into main
Why bother? Because main should always work. You experiment in a branch; only when it's good do you merge it in. On teams, every feature and bug-fix lives in its own branch, and merging happens through a Pull Request on GitHub — a page where teammates review your changes before they join main.
Do this today (10 minutes):
- Create a free account at github.com
- Install Git from git-scm.com
- Make a folder, run
git init, create a file, thenadd→commit→ create a repo on GitHub →push
The full walkthrough is in the Resources tab (the Traversy crash course is 32 minutes and excellent).
.gitignore — keeping junk (and secrets) out 🚫
Not everything in your project folder belongs in the photo album. Two categories you must never commit:
- Generated junk — folders like
node_modules/(downloaded libraries, sometimes gigabytes) or.next/(build output). They can always be regenerated from your actual code, so committing them just bloats the album for no reason. - Secrets — API keys, database passwords,
.envfiles. If you commit a secret once, it lives in your Git history forever, even if you delete the file in a later commit — anyone with repo access (or who finds a leaked public repo) can dig it out. This is a real, common cause of security breaches.
The fix is a file named exactly .gitignore in your project's root, listing what Git should never track:
node_modules/
.env
.next/
*.log
Create it before your first commit. Git will simply skip anything listed here — git status won't even mention it.
Model how git log shows recent history. Write recentCommits(commits, n) where commits is an array of messages in chronological order (oldest first). Return the last n commits, most recent first — exactly what git log -n shows you.
Example: recentCommits(["Init", "Add navbar", "Fix bug", "Add footer"], 2) → ["Add footer", "Fix bug"]
Real-world case study: this exact platform 🔍
This isn't hypothetical — the very site you're learning on is built exactly this way. Its CONTRIBUTING.md tells every contributor to branch off main, commit their roadmap or lesson changes, and open a Pull Request for review before anything merges. Every lesson you've completed on this site shipped through that exact branch → commit → push → Pull Request → merge flow you just learned. Open-source projects you use every day — React, VS Code, Python itself — all run on this same rhythm.
Question 1 of 7
What is a commit?
Question 2 of 7
What's the difference between Git and GitHub?
Question 3 of 7
Which command takes the snapshot?
Question 4 of 7
Why work in a branch instead of directly on main?
Question 5 of 7
What is a Pull Request?
Question 6 of 7
Why should you never commit a .env file with real secrets?
Question 7 of 7
Why skip committing node_modules/?
Summary
- Git = snapshot album on your machine (init, status, add, commit)
.gitignorekeeps junk and secrets out of that album forever- GitHub = your album online (push) + your public portfolio
- Branch = safe parallel universe; merge via Pull Request
- Real open-source projects — including this very site — run on exactly this workflow
Career tip: commit and push something every week. A green GitHub activity graph is one of the strongest signals a junior developer can show an employer.
Practice
Reading is not learning until you run something. Pick one.