Making Commits
Commits are the building blocks of your project's history. In this lesson, you'll learn how to create meaningful commits, write effective commit messages, and follow best practices that will make your repository history clear and useful.
Git Commit Basics
A commit is a snapshot of your repository at a specific point in time. It records what changed, who made the change, when it was made, and why it was made.
# Basic commit command
git commit -m "Your commit message"
# Open default editor for longer message
git commit
# Stage and commit in one step (tracked files only)
git commit -am "Quick commit message"
Key Fact: Every commit in Git has a unique SHA-1 hash (like 2f8a7e9d3b...) that identifies it. This ensures data integrity and makes it easy to reference specific commits.
Commit Message Anatomy
A well-structured commit message has three parts:
Subject Line (Required):
- Short summary (50 characters or less)
- Imperative mood ("Add feature" not "Added feature")
- No period at the end
Body (Optional):
- Detailed explanation of what and why
- Wrapped at 72 characters
- Separated from subject by blank line
Footer (Optional):
- Issue references (Closes #123)
- Breaking changes
- Co-authors
Writing Great Commit Messages
Compare these examples:
❌ Bad Examples:
git commit -m "fixed bug"
git commit -m "updates"
git commit -m "asdfasdf"
git commit -m "Changed some stuff"
✅ Good Examples:
git commit -m "Fix login validation for empty passwords"
git commit -m "Add user avatar upload feature"
git commit -m "Refactor database connection logic"
git commit -m "Update dependencies to latest versions"
Tip: Complete this sentence: "If applied, this commit will..." - your commit message should fit naturally after it. Example: "If applied, this commit will fix login validation for empty passwords."
Using the Editor for Detailed Messages
For complex changes, use the full editor:
# Open editor without -m flag
git commit
# Example of a detailed commit message:
Add user authentication system
Implement JWT-based authentication with the following features:
- User registration with email verification
- Login with username/email and password
- Password reset functionality
- Token refresh mechanism
This addresses security concerns raised in issue #45 and provides
the foundation for role-based access control in future updates.
Closes #45
Conventional Commits Format
Many teams follow the Conventional Commits specification for standardized commit messages:
Format:
<type>(<scope>): <subject>
Common Types:
feat: New feature
fix: Bug fix
docs: Documentation changes
style: Code style (formatting, no logic change)
refactor: Code restructuring (no feature/bug change)
test: Adding or updating tests
chore: Build process, dependencies, tooling
Examples:
feat(auth): add social media login options
fix(cart): prevent duplicate items in shopping cart
docs(api): update authentication endpoint examples
refactor(database): optimize query performance
test(user): add integration tests for registration
Benefits: Conventional Commits make it easy to automatically generate changelogs, determine version bumps, and understand project history at a glance.
Amending Commits
Made a mistake in your last commit? You can fix it:
# Forgot to add a file?
git add forgotten-file.txt
git commit --amend --no-edit
# Want to change the commit message?
git commit --amend -m "Better commit message"
# Open editor to modify message and add more changes
git add another-file.txt
git commit --amend
Warning: Only amend commits that haven't been pushed to a shared repository! Amending changes the commit hash, which can cause issues for collaborators who already have the original commit.
Co-Authored Commits
When pair programming or collaborating, give credit to co-authors:
git commit -m "Implement payment processing system
Co-authored-by: Jane Smith <jane@example.com>
Co-authored-by: Bob Johnson <bob@example.com>"
Best Practices for Commits
✓ DO:
- Make atomic commits (one logical change per commit)
- Commit frequently (at least daily)
- Write descriptive commit messages
- Use imperative mood ("Add" not "Added")
- Reference issues when applicable
- Review changes before committing (git diff --staged)
✗ DON'T:
- Commit unrelated changes together
- Use vague messages like "fix" or "update"
- Commit broken/untested code
- Include sensitive data (passwords, API keys)
- Commit generated files (unless necessary)
- Wait too long between commits
Practical Examples
Let's walk through a complete workflow:
# Make changes to files
echo "console.log('Hello World');" > app.js
# Check status
git status
# Stage the changes
git add app.js
# Review what will be committed
git diff --staged
# Commit with descriptive message
git commit -m "Add initial JavaScript application entry point"
# View commit history
git log --oneline
Multi-Line Commit Messages in Terminal
You can create detailed commit messages directly in the terminal:
# Method 1: Multiple -m flags
git commit -m "Add user profile page" -m "Features included:" -m "- Avatar upload" -m "- Bio editing" -m "- Social links"
# Method 2: Press Enter in quotes (most shells)
git commit -m "Add user profile page
Features included:
- Avatar upload
- Bio editing
- Social links"
Pro Tip: Set up commit message templates to maintain consistency across your team. Create a template file and configure Git to use it: git config --global commit.template ~/.gitmessage
Commit Message Templates
Create a template file for consistent commit messages:
# Create template file: ~/.gitmessage
# Subject line (50 chars max)
# Body: Explain what and why (wrap at 72 chars)
# Footer: Issue references, breaking changes
# Example: Closes #123
# Remember:
# - Use imperative mood ("Add" not "Added")
# - Separate subject from body with blank line
# - Explain the why, not just the what
# Then configure Git to use it:
git config --global commit.template ~/.gitmessage
Practice Exercise:
Scenario: You've added a new password validation feature that checks for minimum length, special characters, and prevents common passwords. Write a commit message following best practices.
Your Task:
- Write a subject line (50 chars or less)
- Add a detailed body explaining what and why
- Include a footer referencing issue #67
Sample Answer:
Add enhanced password validation system
Implement comprehensive password strength checking with:
- Minimum 8 characters requirement
- At least one special character validation
- Common password dictionary check (top 10,000)
- Real-time feedback during user input
This improves account security and addresses user concerns
about weak passwords. The validation happens both on the
client side (instant feedback) and server side (security).
Closes #67
Viewing Your Commit
After committing, verify your work:
# Show last commit details
git show
# Show last commit with file changes
git show HEAD
# Show specific commit
git show 2f8a7e9
# Show commit message only
git log -1
Summary
In this lesson, you learned:
- How to create commits with
git commit
- The anatomy of a great commit message (subject, body, footer)
- Best practices for atomic and meaningful commits
- Conventional Commits format for standardization
- How to amend commits (for unpushed changes only)
- Adding co-authors to collaborative commits
- Using commit message templates for consistency
Next Up: In the next lesson, we'll explore how to view and analyze your project's history using Git log and other powerful commands!