Git & GitHub Fundamentals · Module 03 of 12

Status, staging and commits

Create focused commits by inspecting changes, selectively staging content and verifying the snapshot before committing.

Learning objectives

By the end of this module, you should be able to:

  • Interpret git status --short.
  • Distinguish working-tree diff from staged diff.
  • Create a focused commit with a useful message.

The index lets you choose the next snapshot

You do not have to commit every modified file together. Stage only the logically related changes that belong in the next commit.

Inspect before commit

git diff shows unstaged changes. git diff --cached shows what is staged. A clean working tree after a commit means tracked files match HEAD and there are no untracked files reported.

Commit messages are operational context

A concise subject should explain the change or intent. Good history helps review, debugging, release notes and incident investigation.

Worked examples

See the idea in practice.

Create and inspect a focused commit

printf "alpha\n" > app.txt
git add app.txt
git diff --cached
git commit -m "Add initial application note"
git status --short
  • The staged diff is the exact content proposed for the commit.
  • The commit records a new snapshot and advances the current branch.
Hands-on lab

Lab — Stage deliberately and commit

Goal: Make two files, commit one logical change first, then commit the second.

Before you start

  • Git 2.23 or newer is recommended so the labs can use git switch and git restore.
  • Run labs in a disposable working directory; the included validator creates and removes its own temporary repository.
STEP 1

Initialize and configure

mkdir -p ~/gnu-git-labs/module03 && cd ~/gnu-git-labs/module03
git init -b main
git config user.name "GNU Learner"
git config user.email "learner@example.invalid"
STEP 2

Create two changes

printf "service=web\n" > app.conf
printf "draft\n" > notes.txt
git status --short
STEP 3

Stage only configuration

git add app.conf
git diff --cached
git diff
STEP 4

Commit it

git commit -m "Add web service configuration"
STEP 5

Commit notes separately

git add notes.txt
git commit -m "Add implementation notes"
git status --short

Verify

  • Two commits exist.
  • The final status is clean.
  • The first commit contains app.conf but not notes.txt.

Expected outcome

  • History contains two focused snapshots instead of one unrelated bundle.

If it fails

  • If commit rejects identity, set user.name and user.email locally.
  • If the wrong file is staged, use git restore --staged <file> before committing.
Real-world connection

Small coherent commits make pull-request review and rollback much safer.

Avoid these traps

Common mistakes

  • Running git add . without reviewing what it stages.
  • Using vague messages such as update or fix stuff.
  • Confusing git diff with git diff --cached.
Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What does git diff --cached show?

Changes staged for the next commit.

2Can one working tree contain changes for more than one future commit?

Yes; stage and commit them selectively.

3What should you do before committing sensitive generated files?

Inspect status and the staged diff so they are not accidentally included.