Committing Changes

Analogy categoryAnalogies

A commit is the fundamental unit of history in Git: a durable, named snapshot of the project at a point in time, along with metadata explaining who made the change and why. Running git commit takes whatever is currently in the staging area and permanently records it as a new commit object, advancing the current branch pointer to reference it. Unlike staging, which is fluid and easy to change, a commit is (mostly) immutable once made — modifying it means creating a new commit object with a new hash, not editing the old one in place.

🏏

Cricket analogy: A commit is like an official scorecard entry sealed after each session — it permanently records the day's play and moves the match state forward; you can't erase Sachin Tendulkar's recorded century, only add a new, separately dated correcting entry.

Creating a Commit

The most common form, git commit -m "message", commits the currently staged changes with an inline message. Omitting -m opens your configured editor (see core.editor) for a longer, multi-line message. git commit -a -m "message" is a shortcut that stages all changes to already-tracked files (but not new, untracked files) before committing — convenient, but it bypasses the deliberate selectivity the staging area is designed to offer, so many experienced developers avoid it in favor of explicit git add.

🏏

Cricket analogy: git commit -m is like a quick one-line scorecard note; leaving it blank opens the full match report for detailed notes; -a is like auto-logging every player's stats without individually selecting them, missing any brand-new player not yet on the roster.

bash

# Standard commit with an inline message
git add invoice_service.py
git commit -m "Add idempotency key check to invoice creation"

# Commit with a longer, multi-paragraph message via editor
git commit
# opens configured editor for subject line + blank line + body

# Stage all tracked-file changes and commit in one step (skips new files)
git commit -a -m "Fix rounding error in tax calculation"

# View the resulting commit
git show --stat HEAD

Writing Good Commit Messages

A well-formed commit message has a short, imperative-mood subject line (typically under 50-72 characters, e.g. 'Add retry logic to webhook handler', not 'Added' or 'Adding'), optionally followed by a blank line and a more detailed body explaining the motivation and approach — the 'why', which the diff itself cannot convey. Good messages compound in value over time: git log, git blame, and code archaeology months later depend entirely on whether past-you (or a teammate) left an honest trail of intent.

🏏

Cricket analogy: A well-formed commit message is like a Wisden Almanack entry: a short, active headline ('Kohli reaches maiden double century'), followed by a paragraph on context and significance — decades later, historians rely entirely on that record.

A commit message answers a question the diff cannot: not 'what changed' (the diff shows that precisely) but 'why did this change need to happen.' A commit body explaining 'switched to exponential backoff because the webhook provider rate-limits at 10 req/s' is far more valuable six months later than the diff alone.

What a Commit Actually Records

Structurally, a commit object stores a pointer to a root tree (the full snapshot of staged content), one or more parent commit hashes (linking it into history), author and committer identity/timestamp (which can differ, e.g. when a commit is cherry-picked or applied by someone else), and the message itself. Because the commit's own hash is derived from all of this, committing is not an in-place edit of any prior state — it always creates something new, and the branch pointer simply moves forward to reference it.

🏏

Cricket analogy: A commit object is like a sealed match report card: it references the full scorecard (root tree), links to the previous match's report (parent), records both the player's and recorder's names and date — which can differ if filed late — and its own reference number is generated fresh from all of it.

Committing does not send your changes anywhere beyond your local repository. Many beginners assume git commit shares work with teammates — it does not. Only git push publishes commits to a remote, so uncommitted or unpushed work remains invisible and, if only local, vulnerable to loss.

A commit permanently records a snapshot of staged content along with author, timestamp, message, and parent commit(s).
git commit -m provides an inline message; omitting -m opens your editor for a longer message.
git commit -a stages tracked-file changes automatically but skips new, untracked files — use deliberately, not as a default habit.
Effective commit messages use an imperative-mood subject line and, where useful, a body explaining the 'why' behind the change.
Commits are effectively immutable — 'editing' one always produces a new commit object with a new hash.
Committing is purely local; git push is required to share commits with a remote or with teammates.

Practice what you learned

1. What does the `git commit -a` flag do?

2. Which best describes the relationship between a commit's message and its diff?

3. Why is a Git commit considered effectively immutable?

4. What is a common misconception beginners have about `git commit`?

5. What convention is recommended for a commit's subject line?

Was this page helpful?

The Staging Area

Viewing History with git log

Related Study Notes in Software Engineering

Browse all study notes

Software Engineering

Microservices Study Notes

Software Architecture · 30 topics

Software Engineering

Testing & TDD Study Notes

Software Testing · 30 topics

Software Engineering

Design Patterns Study Notes

Software Design · 30 topics

Software Engineering

Software Engineering Study Notes

Python · 40 topics

Software Engineering

System Design Study Notes

Architecture · 40 topics

Topics covered

#Bash#GitVersionControlStudyNotes#SoftwareEngineering#CommittingChanges#Committing#Changes#Creating#Commit#StudyNotes#SkillVeris

Committing Changes