Git Commit
Write a useful commit message, record a root commit from the index, and prove the snapshot with log, show, and status.
A commit is a recorded snapshot
The previous lesson prepared a Git repository and staged exact files. This lesson records that proposal as history. git commit does not “save files” in the editor sense, and it does not upload anything to GitHub. It writes a snapshot of the index, with your identity and message, as a commit object.
Continue in hello-history from Git Repository, or recreate that state: one README staged, nothing else selected.
Write a useful commit message
A commit message explains why this complete state belongs in history. For the first snapshot, Create project README is specific, short, and written as an imperative action.
“changes”
- Does not identify the outcome.
- Cannot distinguish this commit later.
- Forces the reader to reconstruct intent from the diff.
“Create project README”
- Names the completed outcome.
- Matches the staged content.
- Fits naturally after “This commit will…”
Test what you learned
Which commit subject best describes a snapshot that adds a project README?
Create the root commit
git status
git diff --cached
git commit -m "Create project README"
git status
git log --oneline --decorate -1If the commit succeeds, Git writes a tree from the index, creates a commit object with your configured identity and message, and updates the current branch to point to it. Because no earlier commit exists, this is a root commit with no parent.
The commit output normally includes the branch name, an abbreviated object identifier, the subject, and a file summary. Read it. Command output is evidence, not decoration.
Prove the snapshot exists
git status
git log --oneline --decorate -1
git show --stat --oneline HEAD
git rev-parse --show-toplevel
git ls-tree --name-only HEADSTATUSWorking tree is cleanNo index or working differences remain after the commit—assuming you did not edit again.
LOGThe branch points to one commitThe one-line log shows an abbreviated identifier and your commit subject.
SHOWHEAD has the expected summaryThe commit metadata and file statistics match the snapshot you intended.
TREEREADME belongs to the committed treels-treeproves the path exists in HEAD, independent of the working file.
A clean status does not mean “Git has no files.” It means the working tree and index match the snapshot at HEAD, and there are no reportable untracked paths. Git Log later teaches richer history reading.
Make one edit after the commit
Add a second sentence to README and run git status, git diff, and git diff --cached. Predict the output first:
Status
README is modified but not staged because working content differs from the index.
Plain diff
Shows the new working-tree sentence relative to the index.
Cached diff
Is empty because index and HEAD still match after the previous commit.
HEAD
Still contains the original README snapshot. Editing does not rewrite history.
Leave this edit uncommitted or restore it manually by matching the committed text. The goal is to prove the three-place model after a real commit, not to accumulate unexplained history.
Independent lab: a verifiable root commit
Create a disposable folder named first-snapshot-lab. Add two files: README.md describing the project and notes.txt with one learning goal. Then:
- Initialize the repository if it is not already a Git repository.
- Stage only
README.mdand provenotes.txtremains untracked. - Review the cached diff, then commit only the README with a specific message such as
Create lab README. - Use log, show, and ls-tree to prove what the root commit contains.
- Explain why status is not clean even though the commit succeeded.
Common commit mistakes
Committing without reviewing the index
Run git diff --cached so the message matches the snapshot.
Writing “update” as the subject
State the completed outcome so later git log is readable.
Assuming commit means GitHub
The commit exists locally. No remote has been configured or contacted.
Trusting “success” without proof
Use status, log, show, and tree inspection to verify the resulting state.
Lesson review
You recorded a root commit from a reviewed index, wrote a message that states intent, and proved the snapshot independently of the working file. Later edits stay in the working tree until you stage and commit again.
- I know
git commitrecords the index, not unsaved editor buffers or GitHub. - I can write a commit subject that states the snapshot’s purpose.
- I can prove the root commit with status, log, show, and tree inspection.
- I can explain why editing a file after commit does not change HEAD.