Git records project snapshots and the relationships between them. It is useful before collaboration enters the picture: a small, explainable commit lets you compare a working idea with the previous one and return to a known state. A repository is more than its visible files; .git stores objects, references, configuration and logs of reference movement.
Three places to inspect
The working tree contains the files you edit. The index, also called the staging area, describes the next snapshot you intend to record. HEAD normally names a branch whose tip is the current commit. A commit records a tree, parent commit IDs and metadata. The first commit has no parent; a merge can have more than one. Blobs hold file contents, trees connect names to blobs and subtrees, and commits connect snapshots into history. Git may compress and pack objects internally, so snapshots do not imply a separate physical copy of every file for every commit.
Record a deliberate snapshot
Start a personal practice repository with git init -b main. Configure your identity for that repository with git config user.name "Your Name" and git config user.email "you@example.com"; these are commit metadata, not a hosting-service login. The labs already supply a practice identity and an initialized repository. Inspect git status --short --branch, stage a named path, inspect git diff --cached, then commit with a message describing the change.
git status --short --branch
git add README.md
git diff --cached
git commit -m "Describe the experiment"
git log --onelinegit add stages the file's contents at that moment. Editing it afterward does not silently update the staged version. git commit normally records the index, rather than every visible working-tree change. New untracked files are excluded until added explicitly. git commit -a covers tracked modifications and deletions, but does not discover untracked files for you.
Understand what a name means
A branch name is a movable reference to a commit. A commit ID identifies an object, not a position that changes when a new commit is made. Git installations can use different object hash formats; do not teach every commit ID as a fixed forty-character string. Short IDs must be unambiguous in their repository. git show HEAD:README.md reads that path from the committed tree, even if the working copy now differs.
Try the lab
The first task includes a README worth recording and a scratch draft worth keeping outside the snapshot. Predict which paths will appear in the commit before submitting. Run sample shows an actual Git transcript and the resulting repository. Every run starts fresh, so commands you tried in an earlier run are not carried into the next submission. Finish with a snapshot you can explain: what changed, why it belongs together, and which files deliberately remain outside it.