Making a Commit
A commit is a snapshot of your project at a specific moment. When you commit, Git permanently records all staged changes along with a message describing what changed. Commits create the history you can navigate, review, and return to if something goes wrong.
Creating a Commit
After staging your changes, commit them with a message:
The -m flag lets you write the message inline. Git confirms the commit with a short identifier (like abc1234), the branch name, your message, and a summary of changes.
Writing Good Commit Messages
Your commit message should explain what changed and ideally why. Future you — and anyone else reading the history — will thank you for clear messages.
Good messages:
- "Add user login validation"
- "Fix crash when input is empty"
- "Update dependencies to latest versions"
Less helpful messages:
- "Fixed stuff"
- "Changes"
- "WIP"
Keep messages concise but descriptive. If you need more detail, you can write a longer message by omitting -m — Git will open your default text editor for a multi-line message.
Commits as Save Points
Think of commits as save points in a video game. Each one captures your project's state at that moment. If you break something later, you can return to any previous commit.
This is why committing frequently makes sense. Small, focused commits are easier to understand and easier to undo if needed. Don't wait until you've made dozens of changes — commit logical chunks of work as you go.
What Gets Committed
Only staged changes become part of the commit. If you modified three files but only staged two, the third file's changes won't be included. This is intentional — it lets you control exactly what each commit contains.
After committing, run git status to confirm:
"Working tree clean" means all tracked changes have been committed. You're at a clean save point.
The Commit Workflow
- Make changes
- Stage with
git add - Commit with
git commit -m "message" - Repeat
This rhythm becomes natural quickly. Each commit adds another point to your project's timeline.