Commits
By the end of this lesson
Record focused changes with messages that explain the reason.
A commit records the state of the tracked files at one moment, together with who made it, when, a message, and a link to the commit it followed.
Each commit also gets an identifier: a long string of letters and numbers derived from its contents. You will see it shortened to the first seven characters in most output. That identifier is how you refer to a particular point in history, and because it comes from the content, two commits with different content can never share one.
# See what has changed since the last commit
git status
# Choose the file whose change you want to record
git add src/InvoiceCalculator.cs
# Record it with a message
git commit -m "Round invoice totals to two decimal places"
# Read the history, newest first
git log --oneline
# Look at one commit in full: message, author, and the exact change
git show HEAD- git add names the file to include. Nothing about your folder changes — you are telling Git what the next commit should contain.
- git commit writes the snapshot and the message into the history. Everything staged goes in; everything else stays as an uncommitted change in your working directory.
- git log --oneline gives one line per commit: the shortened identifier and the subject line of the message. This is the view you will use to orient yourself.
- HEAD means the commit you are currently sitting on. git show HEAD therefore displays the commit you made a moment ago, including the exact lines it changed.
The message is the only part the code cannot tell you
Anyone reading history can see what changed — the change itself is stored. What they cannot recover is your reasoning. Compare the same commit described two ways:
| A message that wastes the slot | A message that earns it | |
|---|---|---|
| Subject line | fix | Round invoice totals to two decimal places |
| What a reader learns | Something was wrong somewhere | Which behaviour changed, and where |
| Answers "why?" | No | Yes, once the body is read |
| Useful when tracking down a bug | No — every candidate looks identical | Yes — you can scan the log and narrow it down |
Round invoice totals to two decimal places
Totals were stored at full floating-point precision, so an invoice
for 19.995 displayed as 19.995 on screen and 20.00 on the PDF. Two
customers queried the difference last week.
Rounding now happens once, when the total is calculated, rather than
in each place it is displayed.- Line 1 is the subject: short, and readable on its own in a log listing.
- The blank line after it is not decoration. Git treats the first line as the subject and everything after the blank line as the body, and tools rely on that split.
- The body explains the reason and the consequence. It mentions the customer queries, which no amount of reading the code would reveal.
- Omit the body for genuinely small changes. Never omit it for a decision someone might otherwise undo.
Conventions for the subject line. They are conventions, not rules enforced by Git, but following them makes history far easier to read:
- Write it in the imperative: "Add retry to the payment call", not "Added" or "Adds"
- Keep it to roughly 50 characters so it is not truncated in logs and review tools
- Start with a capital letter and leave off the closing full stop
- Describe the change, not the file — "Reject negative quantities" beats "Update OrderValidator"
- If you need the word "and", you may be describing two commits
Summary
- A commit stores a snapshot, an author, a time, a message and a link to its parent
- Its identifier is derived from its contents, and is usually shown as the first seven characters
- The change records what happened; only the message can record why
- Use a short imperative subject line, a blank line, then a body explaining the reason
- A message that cannot be specific is usually a sign the commit contains too much
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Think about it
Rewrite the message
A commit is titled "fix login". Reading the change shows that the session timeout was increased from 15 minutes to 2 hours.
Write a subject line and a two-sentence body for it. What do you need to know that the change itself does not tell you?
Show solution
A reasonable subject: "Extend session timeout to two hours". It states the behaviour change and would be recognisable in a log a year from now.
The body has to supply what the change cannot: the reason. Perhaps support staff were being logged out mid-call. Perhaps a security review set the figure. Those two reasons lead to opposite decisions if someone later wants to shorten it again.
Notice the gap you had to fill in. When you write the commit, you are the only person who has that information, and the message is the only place it survives.
Try it yourself
Two commits, not one
In a practice repository, add a file describing a product, and separately correct a typo in your README.
Commit them as two separate commits with specific messages. Then run git log --oneline and read it as though you had never seen the repository.
Show solution
Two commits give you two independent records. If the product description turns out to be wrong, you can undo that one commit and keep the typo correction.
With one combined commit you would have to choose between keeping both changes and losing both. That is the practical argument for focused commits, and it matters more as a project grows.
git add products/desk-lamp.md
git commit -m "Add product description for the desk lamp"
git add README.md
git commit -m "Correct the spelling of catalogue in the README"
git log --onelineSaved in this browser only.