Foundation · 45 MINUTES · VERSION 1
Make a useful Git commit and inspect a diff
Review working and staged changes, save small local commits, and prove which content is in the snapshot.
Reviewed 23 Oct 2026Your setup may differ. Windows, Ubuntu, and optional tool bundles →
What you will learn
- Explain working files, staged content, and commits.
- Review the exact change that a commit will save.
- Make two small local practice commits without publishing anything.
Theory: three places to inspect
Git records versions of files in a repository. Your working tree is the files you edit. The staging area, also called the index, holds the content selected for the next commit. A commit saves a snapshot and a message in local history.
Saving a file in your editor does not stage it. Staging a file records its content at that time; later edits are separate. git diff normally compares tracked working files with staged content. git diff --cached compares staged content with the current commit. Review both before committing. An untracked file does not appear in the ordinary diff until you add it.
A small commit should explain one useful change. For example, “Validate task title before saving” is easier to review than “changes.” Commit locally when the change is ready. Sending commits to a remote server is a separate operation. This lesson uses no remote, account, network push, or company code.
Prepare a separate practice folder
Required: Git with git init -b support (Git 2.28 or newer), a text editor, and a terminal. Check git --version. Use your normal compatible Windows or Ubuntu installation; Laragon and XAMPP are not Git requirements.
Create a new empty folder outside existing projects, for example a unique git-study-practice folder inside your personal practice directory. Use File Explorer on Windows or your file manager on Ubuntu. If that name already exists, use another name. Open a terminal in this new folder and confirm its path before running commands. Do not run this exercise in a company repository or this website's project folder.
The following Git commands work in Windows PowerShell, Windows Command Prompt, and Ubuntu Bash. Double quotes around names/messages keep each value together. Commands are separate lines; run them one at a time. If Git opens a pager for a long result, press q to leave the pager.
git init -b main
git config --local user.name "Practice Developer"
git config --local user.email "practice@example.invalid"
The identity settings apply only to this practice repository. They are dummy author details, not a login or a real email address. Your company/global identity settings are not changed. If your personal Git setup requires signing or runs hooks, use a separate ordinary practice environment; do not change a company's signing policy for this lesson.
Worked example: save an initial plan
Use your editor to create notes.txt in the practice folder with these exact two lines. Save as plain UTF-8 text, without a byte-order mark if your editor offers that choice:
Goal: learn Git
Minutes: 20
Run:
git status --short
git add -- notes.txt
git diff --cached -- notes.txt
git commit -m "Add first study plan"
The first status contains ?? notes.txt: Git sees an untracked file. git add stages its current content. The staged diff shows both lines as additions. The commit saves them with the given message. Generated commit IDs vary. Warnings about LF/CRLF can vary with platform configuration; the meaningful text lines should match. Do not change global line-ending settings just to make a screenshot look identical.
Guided practice: separate staged and later edits
- In your editor, change only
Minutes: 20toMinutes: 30and save. - Inspect the working change, then stage it:
git diff -- notes.txt
git add -- notes.txt
- Before committing, change the same line again to
Minutes: 45and save. Do not stage this latest edit yet. - Run:
git status --short
git diff --cached -- notes.txt
git diff -- notes.txt
git commit -m "Increase planned study time to 30 minutes"
git show HEAD:notes.txt
git status --short
Expected evidence:
| Check | Expected result |
|---|---|
| Status before the second commit | MM notes.txt: the file has staged and unstaged changes. |
| Staged diff | Changes 20 to 30. |
| Working diff | Changes 30 to 45. |
git show HEAD:notes.txt after commit |
Contains Minutes: 30. |
| Working file after commit | Still contains Minutes: 45. |
| Final short status | A space then M notes.txt: a remaining unstaged change. |
The commit saves the staged 30-minute plan. It does not automatically include the 45-minute edit made after staging. HEAD identifies the current commit. This distinction matters when a file contains work that is not ready to share.
Independent exercise
Finish the 45-minute update as a third commit. First inspect its diff, stage only notes.txt, review the staged diff, and use a message that explains the change. Verify the committed file contains 45 minutes and that short status is empty. Use git log --oneline -3 to read the three messages.
Create a dummy scratch.txt afterward. Confirm it appears as untracked and is absent from your last commit. Leave it untracked for inspection; no deletion or destructive recovery command is needed. Never put passwords, API keys, real customer data, or a .env file into this exercise. Ignoring a file later does not erase a secret already stored in earlier commits.
Common mistakes
- Committing the wrong directory: confirm the terminal path and use a new practice folder.
- Assuming a saved file is staged: inspect status and the staged diff.
- Assuming later edits replace staged content: stage again only when the newer change is ready.
- Adding every file without review: use a specific path in this exercise.
- Treating a local commit as a backup on another machine: remote sharing and independent backups are separate topics.
Self-check — not graded
- Which command reviews content selected for the next commit?
- After staging 30 and editing to 45, which number does an ordinary commit save?
- Does committing automatically upload your work?
Interview practice
“How do you prepare a change for review?” Explain the focused change, tests, working diff, staged diff, clear commit message, and review request. State what remains uncommitted. A reviewer should be able to reproduce what changed and why.
English practice and glossary
- Repository: Git's history and associated working files.
- Working tree: files you edit.
- Stage: select content for the next commit.
- Diff: a comparison showing changes.
- Commit: a saved snapshot in local history.
- Remote: another repository location used for sharing.
Write: “I changed __ because __. I reviewed __. The commit includes __. The remaining change is __.” Read the report aloud using the actual staged/working evidence.
Recap and next step
Edit, inspect, stage, review, and commit a small change. Staged content and later edits can differ. Next, practise PHP values, types, and strict comparisons. Official command references and review dates appear below.
Reveal exercise hints and self-check answers
git diff --cachedreviews staged changes against the current commit.- It saves 30. The 45-minute edit remains unstaged.
- No. A local commit and a remote push are separate operations.
Independent exercise outline: run git diff -- notes.txt, git add -- notes.txt, git diff --cached -- notes.txt, then git commit -m "Increase planned study time to 45 minutes". Verify git show HEAD:notes.txt and git status --short. The new dummy scratch file should appear as ?? scratch.txt; it should not appear in git show --stat HEAD. Commit IDs, timestamps, and warning text are not fixed expected values.