A repository on GitHub is just a folder of your project, living in the cloud, and every change you keep is saved as a commit. Think of a commit as a snapshot with a sticky note attached. Later you can flip back through all of them, one at a time, and see exactly what the project looked like and when.
About 2 min of reading
I changed the homepage and committed it, but I did not know how many lines git had actually saved or why it said what it said. Let me make a real edit, stage it, and watch a commit become the first entry in a history I can read back months later.
Make a real change to a file that already exists and nothing else. The moment after I write the new line, git considers the file modified, but it is not yet saved into history. git status is the exact thing I look at before every commit, it tells me what is changed and what is not.
Before you run it, say out loud what it will print. Then open the answer.
git add moves that change into staging, the limbo the lesson describes. It is the single command that decides what goes into this snapshot, so I stage just the one file I edited, not everything that might be lying around.
Before you run it, say out loud what it will print. Then open the answer.
Write the message that becomes the sticky note on this commit. The one I wrote says what changed and where, so a teammate (or future me) reading the history later does not have to guess. Pick one and commit.
Before you run it, say out loud what it will print. Then open the answer.
This is the reply I was curious about. git log --oneline prints the whole history, newest at the bottom, oldest at the top, with a short ID and each message you wrote. My new commit is now the newest line, and everything before it is still there.
Before you run it, say out loud what it will print. Then open the answer.
Confirm the snapshot is really there. git show prints the exact contents of the most recent commit, the files it touched and every added and removed line. If the log looked right but I wanted proof of what actually landed, this is the line I run.
Before you run it, say out loud what it will print. Then open the answer.
A repo keeps all your files, their full history, and a message describing each change. It's the single source of truth everyone on the project can fall back to when they can't remember what changed and why.
Small, frequent commits are easy to read in hindsight, and they're your safety net: if one bad change sneaks in, you can undo just that commit without throwing away everything since it.
You: "I changed the homepage."
git add index.html
git commit -m "Fix the homepage button color"git replies with something short and satisfying: 1 file changed, 10 lines added. Each commit makes a snapshot of your work at that moment. Months later you can open the history and read every message, and it tells the story of how the project grew.
git add app.js
git statusBefore you commit, changes sit in a limbo called staging. git add moves a file into that limbo. It's a bit like packing boxes before the movers arrive: you get to decide exactly what goes into this snapshot and what stays for later.
Staging is also how you split one edit into several commits. Change three things but only want to commit one of them? Stage that one, leave the rest.
git log --onelineThis prints your commit history, oldest at the top, newest at the bottom. Each line has a short ID and the message you wrote. It's a quick way to answer the question nobody likes to ask: what did I actually change last week?
Read enough history and you start to see your own habits, the messy commits during a rough day, the clean ones when you knew what you were doing.