Committing

A commit is the fundamental unit of Git. Every time you commit, you are permanently recording a snapshot of your project — a point in time you can always return to, compare against, or share with others. Understanding how to commit well is one of the most important skills in using Git effectively.

What a Commit Actually Is

A commit stores:

• A snapshot of everything in the staging area at the time of the commit.
• The author name and email (from your git config).
• The timestamp of when the commit was made.
• A commit message describing the change.
• A SHA-1 hash — a unique 40-character identifier for that exact snapshot.
• A reference to the parent commit — the commit that came before it.

This chain of parent references is what forms Git's history. Every commit knows where it came from, which is how Git can reconstruct any state of your project at any point in the past.

Making a Commit — git commit

Before committing, your changes must be staged with git add. Only what is in the staging area goes into the commit — nothing more, nothing less.

Committing with an inline message

The most common way to commit is with the -m flag:

git commit -m "Add user authentication to login route"

Git responds with a summary of what was committed:

[main 463dc4f] Add user authentication to login route
 2 files changed, 34 insertions(+), 3 deletions(-)

This tells you:

• The branch the commit went to (main)
• The abbreviated SHA-1 hash of the new commit (463dc4f)
• How many files changed and how many lines were added or removed

Committing with an editor

Running git commit without -m opens your configured text editor with a template:

git commit

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Changes to be committed:
#   modified: app.js
#   new file: README.md

Write your message above the commented lines, save, and close the editor. Git creates the commit using what you wrote.

This approach is useful when you need to write a longer, multi-line commit message — a subject line followed by a detailed explanation.

Writing Good Commit Messages

A commit message is a permanent record in your project history. It is read by your future self, your collaborators, and anyone who needs to understand why a decision was made. Taking it seriously pays dividends over time.

The widely accepted convention

Short summary in 50 characters or fewer

A blank line separates the subject from the body. The body
explains the motivation for the change — not what changed
(the diff already shows that), but why. Wrap lines at 72
characters.

Subject line rules:

• Keep it under 50 characters.
• Write in the imperative mood: "Fix bug" not "Fixed bug" or "Fixes bug."
• Do not end with a period.
• Capitalise the first word.

Body (optional):

• Separate from the subject with a blank line.
• Explain why the change was made, not just what changed.
• Wrap lines at 72 characters.

Examples

Good:

Add rate limiting to the API endpoints

Without rate limiting, the API was vulnerable to abuse from
clients sending excessive requests. This adds a middleware
that restricts each IP to 100 requests per minute, returning
429 Too Many Requests when exceeded.

Poor:

fixed stuff

updated files and made some changes to fix the thing that was broken

The second set tells a future reader nothing useful. When you are debugging a problem six months from now and need to understand why a change was made, good commit messages are invaluable.

Amending the Last Commit — git commit --amend

If you commit and immediately realise you forgot to include a file, or your commit message has a typo, you can fix it without creating a new commit:

git commit --amend

This replaces the last commit with a new one. If you stage additional changes before running --amend, those changes are folded into the replacement commit. If you stage nothing, only the commit message changes.

# Forgot to include a file
git commit -m "Add new feature"
git add forgotten-file.js
git commit --amend

You end up with a single commit, not two. The original commit is replaced — it effectively never happened in the history.

When not to amend

--amend rewrites history. If the commit has already been pushed to a remote repository that others are working from, amending it and force-pushing will cause problems for your collaborators. Only amend commits that exist solely on your local machine and have not been shared.

Skipping the Staging Area — git commit -a

For situations where you want to commit all tracked changes without staging them individually, the -a flag automatically stages every modified tracked file before committing:

git commit -a -m "Update config values"

This is a shortcut — it does not stage new untracked files, only changes to files Git already knows about.

Use it carefully. The staging area exists precisely so you can be deliberate about what goes into each commit. Using -a bypasses that control and can lead to commits that bundle unrelated changes together, making your history harder to follow and debug.

What Goes Into a Commit vs. What Doesn't

This is a source of confusion for beginners. A commit only records what was in the staging area at the time of the commit. Anything modified in the working directory but not staged is left out.

# Only app.js is staged — README.md is modified but not staged
git add app.js
git commit -m "Update app logic"
# README.md changes are NOT in this commit — they remain in the working directory

This is not a mistake — it is intentional design. You can have twenty files modified at once and commit them in small, focused batches. Each commit captures exactly the set of changes you chose.

Atomic Commits

A concept worth understanding early is atomic commits — the practice of making each commit represent one logical, self-contained change. Rather than accumulating a week's worth of changes and committing everything together, you commit each distinct change as its own unit.

Benefits of atomic commits:

• Each commit in the history is meaningful and easy to understand.
• Bugs are easier to track down — you can identify exactly which commit introduced a problem.
• Reverting a specific change is straightforward — you revert one commit, not a bundle of unrelated work.
• Code reviews are easier — reviewers can follow changes one logical step at a time.

A good test: if you can't summarise a commit in a single, clear subject line, it probably contains too many unrelated changes and should be split into multiple commits.

Summary