Repository, Staging and Commits
init, status, add, commit — and why Git has a staging area at all.
- Explain the working tree, staging area and repository as three places
- Initialize a repo, stage changes selectively and create clear commits
- Read git status and git log and interpret what they tell you
Git is not a backup button. It is a snapshot machine: you choose what goes into the next snapshot (staging), then freeze it with a message (commit). Once that model clicks, add/commit/status stop feeling random.
Three places:
- Working tree — the files you edit on disk.
- Staging area (index) — the shortlist of changes for the next commit.
- Repository (.git) — permanent history of committed snapshots.
Daily loop: edit → git status → git add (stage) → git commit → (optionally) git push later.
Why staging? You can commit only the related half of a messy working session. Stage file A, leave file B unstaged, commit a clean unit of work.
Commit messages: subject line under ~72 characters, imperative mood ("Add login form", not "Added"). Body explains why when the why is not obvious.
git status answers: what changed, what is staged, what is untracked. Learn to read the three sections.
History: git log --oneline --graph for a compact view; git show for one commit's diff.
| Status says | Meaning |
|---|---|
| Changes not staged | Edited but not added yet |
| Changes to be committed | Staged for next commit |
| Untracked files | Git has never seen them |
Small commits are reviewable; history is free. Pushing is a separate social/sync decision.
API keys, .env files and tokens must stay out of history — once pushed, treat them as leaked and rotate.
- 1
Step 1 - create and init
mkdir demo && cd demo && git init.
- 2
Step 2 - first file
Create README.md. git status shows it as untracked.
- 3
Step 3 - stage and commit
git add README.md && git commit -m "Add project README".
- 4
Step 4 - second commit
Create app.py, then git add app.py && git commit -m "Add entry script".
- 5
Step 5 - verify history
git log --oneline shows two commits.
Solution
Two clean commits with readable messages; status clean between them.
Edit two files, stage only one, commit, then inspect git status for the other.
Hint: git add path/to/one.txt — not git add . for this drill.
git add . blindly every time
Stages junk, secrets and half-done files. Stage paths you mean to ship.
Vague commit messages like "fix" or "update"
Future you and reviewers need the what/why; use imperative subjects.
What is the staging area for?
It selects which working-tree changes go into the next commit.
Source: Most common Git interview opener.
- Working tree → staging → commit snapshot.
- Stage selectively; commit small with clear messages.
- Status and log are your map at all times.
