Section 1 · Git's Model
Why Version Control, and How Git Thinks
10 min3 min read
Lesson at a glance
Explain what problem version control solves, how Git’s snapshot model differs from saving copies of files, and how Git and GitHub split the work.
No video here — just the real thing: a written lesson, runnable examples, a quiz and practice.
Every developer has a folder somewhere with index.html, index-old.html, index-final.html and index-final-REAL.html. It works until the day you need to know which version had the working menu, what you changed between Tuesday and Thursday, or how to combine your fix with a friend’s edits from the same morning. Copies of files can’t answer any of that.
Version control is the tool for those questions. It keeps a history of your project as a series of saved states, each with a date, an author and a note explaining why. You can compare any two states, return to an old one, try an idea on the side and throw it away, and share the whole history with other people. Git is the version control system almost every team uses in 2026, and GitHub is where most of those teams keep their shared copy.
Snapshots, not edits
Git’s core idea is small. When you commit, Git records a snapshot: the full contents of every file it tracks, at that moment. Files that didn’t change aren’t stored twice; Git reuses what it already has. Each commit also stores a pointer to the commit that came before it, its parent. Follow those pointers backwards and you have the project’s history.
Notice the arrows point backwards. A commit knows its parent, never its children, because the children didn’t exist when it was made. That one detail explains a lot of Git’s behaviour later, including why you can’t “edit” an old commit, only replace it with a new one.
Git versus GitHub
People use the two names as if they were one thing. They aren’t.
- Git is a program on your computer. The whole history lives in a hidden
.gitfolder inside your project. Committing, branching, merging and reading history all happen locally and work on a plane. - GitHub is a website and service that hosts Git repositories. It adds what a team needs around Git: a shared copy everyone pushes to, pull requests for code review, issues, project boards, and GitHub Actions for automated checks.
You can use Git without GitHub (plenty of teams use GitLab or Bitbucket), but GitHub without Git makes no sense. This course teaches Git first, then GitHub on top of it.
What you’ll build
You’ll work on one project all course: your own portfolio site, a repository called portfolio with an index.html, a styles.css, a projects page and a tiny npm test script that checks the HTML. In section 1 you turn the folder into a repository and learn to read its history. In section 2 you branch, merge, rebase and fix a real conflict. In section 3 you put it on GitHub and work through pull requests. In section 4 you learn to undo mistakes safely and finish with a protected main branch where GitHub Actions checks every pull request before it can merge.
Next, you install Git, tell it who you are, and make your first commit.
Key takeaways
- Version control records named, dated snapshots of a whole project so you can compare, undo and share changes safely.
- A Git commit is a snapshot of every tracked file plus a pointer to the commit before it, not a list of edits.
- Git runs on your machine and works offline; GitHub is a hosting service built around Git repositories.
- Most Git confusion disappears once you can draw the commit graph and say where your branch and HEAD point.