Phase 1: Git for Real Work · ~35 minutes · git

What Git Actually Tracks

"git commit" didn't skip your changes. It committed exactly what you staged — and you never staged that file at all.

Hiring signal: Reads git status before committing out of habit, not after being confused by what a commit actually contains

What you will learn

Explain a commit as a real snapshot in a content-addressed history, not a diff
Explain the staging area as a real, meaningful intermediate step, not a formality
Use git status and git diff to see exactly what Git currently thinks is true
Diagnose a commit that silently missed a file due to a forgotten git add

Introduction

Type: Learn Languages: Git Prerequisites: Phase 00 (Command Line & OS Literacy) Time: ~35 minutes

Objective

Learning objectives

Explain a commit as a real snapshot in a content-addressed history, not a diff
Explain the staging area as a real, meaningful intermediate step, not a formality
Use git status and git diff to see exactly what Git currently thinks is true
Diagnose a commit that silently missed a file due to a forgotten git add

What you're building

A small real project with at least 2 files:

Make edits to both files
Deliberately stage and commit only one of them (reproducing this lesson's trap on purpose)
Use git status and git diff to discover the second file's edits are still uncommitted — save the real output of both commands
Stage and commit the second file, and confirm with git status that the working tree is now clean
Write git_notes.txt explaining, in your own words, why the commit "succeeded" without an error even though it didn't include everything you'd changed

You edit two files, run git add file_a.py, then git commit -m "update", then edit file_a.py again (a second, different change) without running git add again. What will git status show?

Staging and committing captures a file's content at that exact moment — it doesn't create an ongoing link that automatically includes future edits to the same file. The second edit to file_a.py, made after the commit, is a brand-new unstaged change, exactly like file_b.py's edits (which were never staged at all, at any point). git status treats both as unstaged changes needing their own git add, because that's precisely what they are — staging is a one-time action on the content that existed when you ran it, not a standing subscription to a file's future changes.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.