Before touching any commands, let's understand what git actually does.
When you work on a project — a website, an app, a document — you make changes over time. Git lets you save snapshots of your entire project at any point. Each snapshot is called a commit. Think of a commit as pressing a "save" button that remembers the exact state of every file.
Analogy
Most people think git records every individual edit, like Track Changes in Google Docs. It doesn't. Git is more like a photo album. Every commit is a complete photograph of your entire project at that moment. Git stores "what everything looks like right now," not "what changed since last time."
Scrub through history
Each "frame" below represents one commit (one saved snapshot). Drag the slider to move through time and see what files existed at each point:
Commit 1 of 5: "Initial project setup"
Key insight
Every file in git gets a unique fingerprint called a hash — a long string of letters and numbers (like e7a1f2d9b3...) computed from the file's contents. If even one character in the file changes, the fingerprint is completely different. This means git can instantly detect any change, and two identical files always share the same fingerprint — so git never stores duplicate copies.
2. The Three Areas
Saving in git is a two-step process (not just one click). Every file in your project lives in one of three places:
Working Directory — the actual folder on your computer where you edit files
Staging Area — a "preparation zone" where you select which changes to include in the next save
Repository — the permanent history of all saved snapshots (commits)
Drag the files through the workflow: first to staging, then to the repository.
Working Directory
login.py
utils.py
README.md
Staging Area
Repository
Analogy
Working directory = your desk. Staging = putting a letter in an envelope. Commit = dropping it in the mailbox. You can keep editing on your desk without affecting what's already mailed.
Why staging exists
Changed 5 files but only want to commit 2? Drag just those 2 to staging, then to the repo. The other 3 stay in your working directory. Surgical precision over what goes into each commit.
3. Inside .git — How Git Stores Your Files
When you run git init in a folder, git creates a hidden folder called .git/ inside it. This is where ALL of your project's history lives. Everything git knows is stored as one of 4 types of objects. Click each step to see how git builds a commit from your files:
Click "Hash the files" to begin...
Each step reveals how git internally creates a commit.
4. Terminal Sandbox
Git is controlled by typing commands into a terminal (also called command line or console) — the black text window that programmers use. Instead of clicking buttons, you type instructions like git add file.txt.
Below is a simulated terminal. Type git init and press Enter to create a new repository (this tells git to start tracking files in this folder).
Hint:Start with git init to create a new repository.
5. Branches — Parallel Timelines
Imagine you want to try a new idea without risking your working code. A branch lets you create a parallel timeline — a separate line of development where you can experiment freely. If it works, you merge it back. If not, you throw it away. Your original code stays safe.
The revelation
Under the hood, a branch is incredibly simple: it is just a tiny text file that stores the ID (hash) of the latest commit on that branch. Creating a branch doesn't copy any files — it just creates this tiny file. That's why branching in git is instant and free.
Click each step to build the visualization:
Click step 1 to begin.
HEAD
HEAD is git's way of knowing "which branch am I currently working on?" It is a marker that points to your current branch. When you make a new commit, it gets added to whichever branch HEAD is pointing at. So: HEAD tells git your current branch, and the branch tells git your latest commit.
What's next
Now main and feature have diverged — they each have commits the other doesn't. How do we bring them back together? That's merging, and it's the next section.
6. Merging — Bringing Branches Together
Remember where we left off? Main and feature have diverged — each has commits the other doesn't. Merging is how you combine them back into one branch. Click the steps to see how it works:
Click step 1 to begin.
The merge commit
A merge commit is special — it has two parents instead of one. It points back to both the last commit on main (F) AND the last commit on feature (D). This is how git records that two lines of history were combined. No code is lost — the full history of both branches is preserved.
But what if there's a conflict?
Most of the time, git merges automatically — if the two branches edited different files (or different parts of the same file), git combines them with no problem. But if both branches changed the same line in the same file, git can't decide which version to keep. This is a merge conflict.
The scenario
You ran git merge feature. Both branches edited line 3 of auth.py. Git inserted special markers to show you both versions:
• The text between <<<<<<< HEAD and ======= is your branch's version
• The text between ======= and >>>>>>> feature is the other branch's version
Your job: edit the file to keep the code you want and delete all the marker lines.
Edit the file to resolve the conflict:
Key insight
Conflict markers are just text: <<<<<<<, =======, >>>>>>>. Remove them, keep the code you want (or combine both), then git add auth.py and git commit. The merge is complete.
7. Rebase vs Merge
There are two strategies to combine branches. Merge keeps the full history showing that a branch existed. Rebase rewrites history to make it look like your work happened after everything else, creating a clean straight line. Click to toggle between them and see the difference:
When to merge
Click to reveal
You want to preserve history — show the branch existed
The branch was shared with others
Safer — never rewrites history
When to rebase
Click to reveal
You want clean, linear history
Your branch is local only (not shared with others)
Dangerous if misused — changes commit IDs, which confuses anyone who had the old versions
If merge is safer, why would anyone rebase?
Good question. Here are three real scenarios where rebase is the better choice:
1
Cleaning up before a pull request
You've been working on a feature branch for a week. You have 14 commits: "wip", "fix typo", "oops forgot file", "actually fix the bug", etc. Before asking your team to review this, you run git rebase -i (interactive rebase) to squash those 14 messy commits into 3 clean ones: "Add user search", "Add search filters", "Add search tests." Your reviewers see a clean story instead of your chaotic process. This is the #1 reason people rebase.
2
Staying up to date with main
You're working on a feature branch, but main keeps getting new commits from your teammates. If you git merge main into your branch every day, you end up with dozens of merge commits cluttering your branch's history. Instead, git rebase main replays your work on top of the latest main — as if you started your branch today. Your branch stays clean with only YOUR commits, and when you finally merge the feature into main, the history reads like a straight line.
3
Open source contributions
You submit a pull request to a popular project. The maintainer says "looks good, but please rebase on latest main." Why? The project's main branch has moved forward since you started. If you merge, the project's git log gets a merge commit that says nothing useful. If you rebase, your commits sit neatly on top of the latest code, making the history easy to read and git bisect (bug hunting) easy to run. Most open source projects require rebased PRs for this reason.
The rule of thumb
Rebase your own local work before sharing it. Never rebase something that's already been pushed and shared. Think of it as editing a draft before publishing. Once it's published (pushed), don't change history — use merge instead.
Interactive Rebase — Full Walkthrough
Let's do it for real. You've been working on a search feature for a week. Here's what your git log looks like — 14 commits of raw, messy progress:
git log --oneline
Click step 1 to see your messy commit history.
Click on pick to cycle through actions: pick (keep as-is) → squash (merge into commit above) → drop (delete) → back to pick
8. Undo: Reset vs Revert
Everyone makes mistakes. You saved (committed) something wrong and need to undo it. Git gives you three options, and they work very differently. Click each one to see what happens:
Your commit history: A → B → C (the bad commit you want to undo) ← you are here
Reset --soft
git reset --soft HEAD~1
Reset --hard
git reset --hard HEAD~1
Revert
git revert HEAD
9. The Reflog — Git's Safety Net
The secret
Think you lost your work? Almost certainly not. Git secretly keeps a log called the reflog (short for "reference log") — a diary recording every action you've taken. Even if you accidentally deleted commits with git reset --hard, the reflog remembers where everything was, and you can restore it.
Mission: Recover the lost commit
You accidentally ran git reset --hard HEAD~2 (which means "go back 2 commits and erase everything after that"). Your last two commits, D and E, have disappeared from your branch. But the reflog below shows every recent action. Each entry has a hash (the commit's ID) and a description. Which entry do you need to return to?
git reflog
c3f1a2bHEAD@{0}reset: moving to HEAD~2
e7d4f9aHEAD@{1}commit: Add payment processing
b2a8c1eHEAD@{2}commit: Fix auth validation
c3f1a2bHEAD@{3}commit: Update database schema
a1b5d3fHEAD@{4}commit: Initial setup
Which reflog entry should you reset to in order to recover both lost commits?
10. Stash — The Clipboard
Scenario
You are mid-feature, files half-edited. Suddenly a critical bug is reported on main. You need to switch branches, but you can't commit half-done work. What do you do?
Click each step to handle the interruption:
1
git stash — Save your work-in-progress to a hidden shelf
Your changes are saved and the working directory is clean. The stash is a special storage area — like sliding your messy desk into a drawer. You can have multiple stashes stacked up.
2
git checkout main — Switch to fix the bug
With a clean working directory, you can safely switch branches. Fix the bug, commit it, push. Crisis handled.
3
git checkout feature — Return to your feature
Back on the feature branch. But your half-done work is still hidden in the stash.
4
git stash pop — Restore your work-in-progress
Your uncommitted changes are restored exactly as you left them. The stash entry is removed. It is as if the interruption never happened. Stash commands:git stash list (see all stashes), git stash drop (discard one), git stash apply (restore without removing).
11. Remotes — Working With Others
So far, everything has been on your own computer. But git is built for collaboration. A remote is a copy of your project stored somewhere else — usually on a website like GitHub. The word "origin" is git's default nickname for the remote you cloned from.
Key insight
Your laptop's copy and GitHub's copy are equals. Both have the full history. GitHub is not "the master" — it's just another copy that's accessible online so your team can share work through it.
Click each step to see how changes flow between your laptop and GitHub:
Your Laptop
main: A—B—C
GitHub (origin)
main: A—B—C
Click step 1 to begin.
git fetch vs git pull
Click to reveal
fetch downloads new commits from GitHub but does NOT merge them into your branch. pull = fetch + merge (download AND combine in one step). Fetch is safer — you can look at what changed before merging. origin/main is your local copy of what GitHub's main branch looks like.
git clone
Click to reveal
Downloads a complete copy of a project from GitHub to your computer. Gets ALL the history, ALL branches, everything. Automatically sets up origin as a nickname for the GitHub URL you cloned from. You now have your own fully independent copy.
12. .gitignore — The Bouncer
Not every file in your project should be saved by git. For example:
.env files contain passwords and secret keys — you never want these shared publicly
node_modules/ is a folder with thousands of downloaded library files — too large and easily re-downloaded
.DS_Store is a hidden Mac file that tracks folder display settings — irrelevant to your project
The .gitignore file is a simple text file where you list patterns of files that git should completely ignore. Type patterns below to practice.
Goal: ignore the junk files without ignoring source code
.gitignore
Pattern syntax
*.log = all .log files. build/ = the build folder. !important.log = except this file. **/*.pyc = all .pyc files in any subdirectory. Lines starting with # are comments.
13. GitHub — Pull Requests
A Pull Request (or "PR") is how you propose changes to someone else's project on GitHub. It's not a git feature — it's a GitHub feature built on top of git. The name means: "I'm requesting that you pull my changes into your project." Walk through the flow:
1
Fork — Make your own copy of someone else's project
A "fork" is a personal copy of someone else's project on your GitHub account. Click "Fork" on github.com/project/repo and GitHub creates github.com/you/repo. You can now make changes to your copy without affecting the original.
2
Clone & Branch — Download it and start working
git clone downloads your fork to your computer. Then git checkout -b fix-bug creates a new branch (a parallel timeline) for your changes. Make your edits, commit them, then upload your branch to GitHub with git push origin fix-bug.
3
Open PR — Ask upstream to merge your branch
On GitHub, create a PR: "Please merge you/repo:fix-bug into project/repo:main." Write a description, attach screenshots, reference issues.
4
Review — Teammates review your code
Reviewers read the diff line-by-line. They can comment, approve, or request changes. Push more commits to address feedback — the PR updates automatically.
5
Merge — Your code enters the official project
A maintainer clicks "Merge." Your commits are now in the official repo. Sync your fork: git pull upstream main && git push origin main. Delete your feature branch.
14. Git Bisect — Bug Detective
Your todo app's delete button is broken. Users can't remove items anymore. You know it worked a week ago but it's broken now. Somewhere in the last 8 commits, someone broke it. You could check every commit one by one — or use git bisect, which finds the broken commit in just 3 steps by splitting the search in half each time.
The mission
Bisect picks a commit for you. Run the tests to see if delete works at that point. Then tell bisect: good (tests pass) or bad (tests fail). Find the guilty commit!
$ npm test
15. CI/CD — The Automation Layer
CI/CD stands for Continuous Integration / Continuous Deployment. In plain terms: it's an automatic system that tests and publishes your code every time you push changes. You don't run tests manually — the system does it for you, automatically, every time. GitHub's CI/CD system is called GitHub Actions.
Analogy
CI/CD is a diligent robot coworker who, every time you push code, immediately sets up a clean computer, installs everything, runs all tests, and reports back. In 2 minutes. Every single time.
Click each stage to see what happens:
Trigger
Push / PR
You push code. GitHub automatically detects this and starts the pipeline.
Setup
Clean Computer
A brand new virtual computer starts up in the cloud. It's a fresh, empty machine. Your code is downloaded onto it and all required libraries are installed.
Test
Run Tests
Automated tests check that your code works correctly. "Linting" checks for style and formatting issues (like a spell-checker for code). If ANY test fails, the pipeline stops and tells you what broke.
Build
Build App
Your code is compiled and packaged into a form ready to deploy (put on a real server). This packaged version is called the "build" — the final product ready to ship.
Deploy
Ship It
The build is published to the live server so real users see it. This only happens on the main branch, and only if all tests pass. Fully automated.
The config file
This is written in YAML — a simple format for configuration files that uses indentation and colons (like a structured to-do list). It lives in your project at .github/workflows/.
.github/workflows/ci.yml
name: CI Pipeline
on: [push, pull_request] # When to run: on every push or PR
jobs:
test:
runs-on: ubuntu-latest # Use a Linux virtual machine
steps:
- uses: actions/checkout@v4 # Download the code
- run: npm install # Install libraries
- run: npm test # Run the tests
deploy:
needs: test # Only runs after tests pass
if: github.ref == 'refs/heads/main' # Only on main branch
steps:
- run: ./deploy.sh # Publish to live server
16. Command Speed Round
Name the right git command. 15 seconds per question. 10 random questions. Shuffled each time you play.
17. Knowledge Assessment
10 questions testing your understanding of how git works under the hood. Take your time.
Q1: What does git store in each commit?
Q2: What is a git branch, physically?
Q3: What is the difference between git reset --hard and git revert?
Q4: You accidentally ran git reset --hard. How can you recover?
Q5: What makes a merge commit different from a regular commit?
Q6: What are the four object types in git's internal database?
Q7: What is the staging area for?
Q8: Why does git push sometimes fail?
Q9: What does git rebase do differently from git merge?
Q10: What is HEAD?
Congratulations!
You've completed the Git Interactive Crash Course.
Git Interactive Crash Course
Certificate of Completion
THIS CERTIFIES THAT
—
has completed the Git Interactive Crash Course and demonstrated understanding of Git version control