Learn / Git & Version Control / Commits & History
Lesson 2 of 6

Commits & History

Think of a video game with a save system. You don't save automatically after every single keystroke — you play until you reach a meaningful checkpoint, then save. Git commits work the same way: you don't commit every keystroke, you group related changes together and save a checkpoint you can always return to. Getting there takes three ingredients: a repository, a staging area, and the commit itself.

💡 The Bottom Line

git init starts tracking a project. git add chooses what goes into the next snapshot. git commit saves that snapshot permanently, with a message explaining why. The staging area between "add" and "commit" is what lets you build a clean, deliberate snapshot instead of committing every stray change in your working folder.

Starting a repository

A Git repository ("repo") is just a project folder with a hidden .git subfolder where all the history lives. You create one with:

cd my-project
git init

That's it — Git is now watching this folder. Nothing is tracked yet; init just creates the empty history for you to start filling in.

The staging area: a loading dock for your next commit

New and changed files in your folder don't go straight into history. They first sit in Git's staging area (also called "the index") — a holding zone where you build up exactly what the next commit will contain.

# edit some files, then stage the ones you want in the next snapshot
git add index.html
git add styles.css

# or stage everything that changed
git add .

Staging matters because it lets you commit in logical, reviewable chunks. If you fixed a bug and also renamed a variable while you were in there, you can stage and commit the bug fix on its own, then stage and commit the rename separately — two clean commits instead of one tangled one.

🙋 There Are No Dumb Questions

Q: Why not just commit everything directly, and skip staging?
A: You can — git commit -am "message" stages and commits all tracked, modified files in one step. But staging exists for the moments it matters: when your working folder has several unrelated changes mixed together and you want to split them into separate, well-described commits instead of one commit that does three things at once.

Making the commit

git commit -m "Add responsive navbar for mobile screens"

This takes everything currently staged and seals it into a permanent snapshot, tagged with your name, the timestamp, and that message. Each commit also stores a reference to the commit before it — which is exactly how Git builds up a full, connected history over time.

⚠️ Watch Out

Vague commit messages like "fix", "updates", or "asdf" cost you later — six months from now, git log full of messages like that tells you nothing about what actually happened. Write commit messages in the imperative mood ("Add," "Fix," "Remove," not "Added" or "Fixes") and describe why, not just what: "Fix off-by-one error in pagination" beats "fix bug" every time.

Reading the history back

Once you have a few commits, git log shows the trail:

git log

commit 8f3e21a9c4b7d... (HEAD -> main)
Author: Ada Lovelace <[email protected]>
Date:   Thu Jul 9 14:02:11 2026 +0530

    Add responsive navbar for mobile screens

commit 1a2b3c4d5e6f7...
Author: Ada Lovelace <[email protected]>
Date:   Wed Jul 8 09:41:07 2026 +0530

    Initial commit

For a quick, scannable view, most people reach for the condensed form instead:

git log --oneline

8f3e21a Add responsive navbar for mobile screens
1a2b3c4 Initial commit

Each of those short codes (like 8f3e21a) is a shortened commit hash — a unique ID you can use later to reference, compare, or return to that exact snapshot.

🔧 Try It Yourself

Create a new folder, initialize it, and make two real commits:

mkdir git-practice && cd git-practice
git init
echo "# My Project" > README.md
git add README.md
git commit -m "Add project README"

echo "console.log('hello');" > app.js
git add app.js
git commit -m "Add initial app entry point"

git log --oneline

Confirm you see both commits listed, oldest at the bottom, with short hashes and your messages next to them.

✅ Quick Check

What is the purpose of the staging area between editing files and running git commit?

Next up: commits so far have all lived on one line. Branching is how Git lets you work on several lines of development at once, safely.

← Back to
Next →