The git commit Command Explained: Creating Snapshots and Writing Professional Commit Messages

In the previous article, we learned how the git add command moves changes from the Working Directory to the Staging Area.

But staged changes are not yet permanently stored in Git's project history.

To save those changes as a permanent snapshot, we use the git commit command.

The git commit command is one of the most important commands in Git. Every feature, bug fix, documentation update, and important project change can be recorded through commits.

A well-maintained Git project may contain hundreds or even thousands of commits.

Each commit tells a small part of the project's story.

In this article, you will learn:

• What a Git commit is

• What the git commit command does

• How to create your first commit

• What a commit contains

• What a Commit ID or hash is

• How Git creates project snapshots

• How to write professional commit messages

• Common commit message mistakes

• Best practices for creating clean commits

By the end of this article, you will understand how Git permanently records your project's history.

---

What is a Git Commit?

A commit is a saved snapshot of your project at a particular point in time.

Suppose you are developing a Student Management System.

Your project may progress like this:

Commit 1 → Create project structure

Commit 2 → Add student registration

Commit 3 → Add login system

Commit 4 → Add marks module

Commit 5 → Fix login validation bug

Each commit represents an important stage in the development of the project.

You can think of commits as checkpoints in a video game.

If something goes wrong later, you can examine or return to an earlier checkpoint.

---

What Does git commit Do?

The git commit command records the changes currently stored in the Staging Area.

The basic workflow is:

Working Directory
        │
        │ git add
        ▼
   Staging Area
        │
        │ git commit
        ▼
 Local Repository

The git add command prepares changes.

The git commit command records those prepared changes in the repository's history.

A simple way to remember this is:

git add    = Prepare changes

git commit = Record snapshot

---

Basic Syntax of git commit

The basic command is:

git commit

However, beginners commonly use:

git commit -m "Commit message"

The -m option allows you to write the commit message directly in the terminal.

For example:

git commit -m "Add student registration feature"

Here:

git commit

creates the commit.

The option:

-m

means message.

And:

"Add student registration feature"

is the commit message.

---

Creating Your First Commit

Let us create a practical example.

Create a folder named:

CommitPractice

Open the terminal inside the folder.

Run:

git init

Now create a file:

Main.java

Add the following code:

public class Main
{
    public static void main(String args[])
    {
        System.out.println("Learning Git Commit");
    }
}

Save the file.

Now run:

git status

Git may display:

Untracked files:

        Main.java

The file is currently untracked.

---

Step 1: Stage the File

Run:

git add Main.java

Now check the repository status:

git status

You may see:

Changes to be committed:

        new file:   Main.java

The file is now staged.

---

Step 2: Create the Commit

Run:

git commit -m "Add Main Java program"

Git may display output similar to:

[main (root-commit) a3f72b1] Add Main Java program
 1 file changed, 7 insertions(+)
 create mode 100644 Main.java

Congratulations!

You have created a Git commit.

---

Understanding the Commit Output

Let us examine the output carefully.

[main (root-commit) a3f72b1] Add Main Java program

This line contains several pieces of information.

---

Understanding main

The word:

main

represents the branch where the commit was created.

Currently, you are working on the main branch.

Branches will be explained in detail later in this series.

---

What is a Root Commit?

The output may contain:

root-commit

A root commit is the first commit in a Git repository.

It has no previous commit.

Consider this history:

Commit A
    ↓
Commit B
    ↓
Commit C

Commit A is the root commit.

It is the starting point of the repository's history.

---

What is a Commit ID?

The output may contain something like:

a3f72b1

This is a shortened version of the Commit ID.

A Commit ID is a unique identifier assigned to every commit.

It is also commonly called:

• Commit Hash

• SHA Hash

• Commit SHA

A complete commit hash may look like:

a3f72b18e91c457c2c419d5a7a4821d729f01345

Git often displays a shorter version because the full hash is long.

---

Why Does Every Commit Need an ID?

Imagine your repository contains 10,000 commits.

Git needs a reliable way to identify each individual commit.

Commit messages may be repeated.

For example:

Fix bug
Fix bug
Fix bug

The messages are identical.

But the Commit IDs are different.

Example:

a3f72b1 → Fix bug

d98e21c → Fix bug

72a4fd9 → Fix bug

The Commit ID uniquely identifies a specific commit.

---

What Does a Git Commit Contain?

A Git commit stores important information.

Conceptually, a commit contains:

Commit
│
├── Project Snapshot
├── Author Name
├── Author Email
├── Date and Time
├── Commit Message
├── Parent Commit
└── Commit ID

Let us understand each part.

---

Project Snapshot

Git records the state of the staged project files.

This represents the project at the moment the commit was created.

---

Author Name

Git records the developer's name.

This comes from:

git config user.name

Example:

Rahul Sharma

---

Author Email

Git also records the author's email.

This comes from:

git config user.email

Example:

rahul@example.com

---

Date and Time

Git records when the commit was created.

This helps developers understand the project timeline.

---

Commit Message

The commit message explains why or what changes were made.

Example:

Add student registration feature

---

Parent Commit

Most commits point to a previous commit.

Suppose the history is:

Commit A
    ↓
Commit B
    ↓
Commit C

Commit C points to Commit B.

Commit B points to Commit A.

Commit A is the root commit and has no parent.

This connection creates Git's project history.

---

How Git Creates Project History

Suppose you create three commits.

First Commit

git commit -m "Create project structure"

Second Commit

git commit -m "Add login feature"

Third Commit

git commit -m "Add student dashboard"

The history becomes:

Create Project Structure
          │
          ▼
    Add Login Feature
          │
          ▼
  Add Student Dashboard

Each commit points to its previous commit.

This creates a chain of project history.

---

Does Git Store the Entire Project Every Time?

A beginner-friendly explanation is that Git creates a snapshot of the project.

Suppose your project contains:

Main.java
Student.java
Database.java

When you create a commit, Git records the state of the project.

Later, you modify Student.java.

The next commit represents the new state of the project.

Git uses an efficient object storage system and reuses unchanged file content instead of unnecessarily storing identical data repeatedly.

Therefore, Git remains efficient even when a project contains thousands of commits.

---

Understanding Commit Messages

A commit message explains the purpose of a commit.

Example:

git commit -m "Add login validation"

A good commit message should quickly answer:

What change does this commit introduce?

Commit messages are extremely important when working in teams.

---

Bad Commit Messages

Avoid messages like:

Update

Changes

Done

Final

Fix

Code updated

asdf

These messages provide almost no useful information.

Imagine reading this history:

Update
Update
Fix
Done
Final
Final 2
Changes

It is impossible to understand what happened in the project.

---

Good Commit Messages

Better messages include:

Add student login feature

Fix incorrect password validation

Update database connection settings

Add responsive navigation menu

Remove unused payment service

Improve README installation instructions

These messages clearly explain the purpose of each commit.

---

Writing Professional Commit Messages

A good commit message should be:

• Short

• Clear

• Specific

• Meaningful

• Action-oriented

A common style is:

Verb + Change

Examples:

Add login feature

Fix payment validation

Update user dashboard

Remove unused CSS

Improve database performance

---

Common Commit Message Verbs

You can use verbs such as:

Verb	Purpose
Add	Introduce something new
Fix	Correct a bug
Update	Modify existing functionality
Remove	Delete something
Improve	Enhance existing functionality
Refactor	Restructure code
Rename	Change a name
Document	Add or improve documentation
Test	Add or update tests
Configure	Change project configuration

Examples:

Add user registration

Fix login redirect bug

Refactor database service

Remove deprecated API method

---

One Commit Should Represent One Logical Change

Suppose you perform the following tasks:

• Add login feature

• Fix payment bug

• Update README

• Change navbar design

You should avoid creating one commit:

Update project

Instead, create separate commits:

Add login feature

Fix payment calculation bug

Update README installation guide

Improve navbar design

This creates a clean and understandable history.

---

Why Small Commits Are Better

Small commits provide several benefits.

Easier Code Review

Developers can understand changes quickly.

Easier Bug Tracking

You can identify which commit introduced a problem.

Easier Reverting

A specific change can be reversed without affecting unrelated work.

Better Project History

The Git history becomes a readable timeline of development.

---

Checking Status After a Commit

After creating a commit, run:

git status

You may see:

On branch main
nothing to commit, working tree clean

This means:

• No files are modified.

• No files are staged.

• Your Working Directory matches the latest commit.

The repository is currently clean.

---

Creating a Second Commit

Now modify Main.java.

Change:

System.out.println("Learning Git Commit");

to:

System.out.println("Mastering Git Commit");

Save the file.

Run:

git status

The file appears as modified.

Stage the changes:

git add Main.java

Create another commit:

git commit -m "Update welcome message"

Your history now contains two commits:

Add Main Java program
          │
          ▼
Update welcome message

---

What Happens If Nothing is Staged?

Suppose your Working Directory is clean.

Run:

git commit -m "Test commit"

Git may display:

nothing to commit, working tree clean

Git does not create an empty commit by default.

There must normally be staged changes before creating a commit.

---

Using git commit Without -m

You can run:

git commit

Git opens the configured text editor.

You can then write a commit message.

For example:

Add student registration feature

Create registration form and validate student details.

Save and close the editor.

Git creates the commit.

This approach is useful for longer commit messages.

---

Writing Multi-Line Commit Messages

A professional commit message may contain:

Add student registration feature

Create the student registration form.
Add email validation.
Store student details in the database.

The first line is the short summary.

The remaining lines provide additional details.

A common structure is:

Short Summary

Detailed Explanation

This is useful for complex changes.

---

The git commit -a Option

Git provides the -a option.

Example:

git commit -a -m "Update student validation"

This automatically stages modified and deleted tracked files before creating the commit.

However, it does not automatically include new untracked files.

For example:

Main.java     → Tracked and Modified
Student.java  → New and Untracked

Running:

git commit -a -m "Update project"

may include Main.java.

But Student.java will not be included because it is untracked.

Beginners should usually follow the clearer workflow:

git status

git add <filename>

git commit -m "Meaningful message"

This gives better control over the commit.

---

Can You Change the Last Commit Message?

Yes.

Suppose you accidentally create:

git commit -m "Updat login"

You notice the spelling mistake.

You can change the most recent commit message using:

git commit --amend -m "Update login"

The last commit is replaced with a new corrected commit.

Be careful when amending commits that have already been shared with other developers.

We will study commit amendment in greater detail later.

---

Practical Git Commit Workflow

A professional beginner-friendly workflow is:

Edit Files
    ↓
git status
    ↓
Review Changes
    ↓
git add <selected files>
    ↓
git status
    ↓
Review Staged Files
    ↓
git commit -m "Meaningful message"
    ↓
git status

Example:

git status

git add Login.java

git status

git commit -m "Add user login validation"

git status

This workflow helps prevent accidental commits.

---

Real-World Example: Student Management System

Suppose you are developing a Student Management System.

Day 1

Create project structure.

git commit -m "Create project structure"

Day 2

Create student registration.

git commit -m "Add student registration"

Day 3

Create login system.

git commit -m "Add student login"

Day 4

Fix login problem.

git commit -m "Fix invalid password handling"

Day 5

Update documentation.

git commit -m "Update installation instructions"

Your Git history now tells a clear story:

Create project structure
        ↓
Add student registration
        ↓
Add student login
        ↓
Fix invalid password handling
        ↓
Update installation instructions

Anyone reading this history can understand how the project developed.

---

Common Beginner Mistakes

Mistake 1: Using Meaningless Commit Messages

Avoid:

Update

Done

Final

Use specific messages.

---

Mistake 2: Committing Everything Together

Do not combine unrelated changes into one commit.

Create focused commits.

---

Mistake 3: Forgetting to Stage Changes

If changes are not staged, they will not be included in a normal git commit.

Always check:

git status

---

Mistake 4: Creating Extremely Large Commits

A commit containing hundreds of unrelated changes is difficult to review and maintain.

Commit logical changes separately.

---

Mistake 5: Including Secrets in a Commit

Never commit:

• Passwords

• API keys

• Database passwords

• Private tokens

• Secret configuration files

Once sensitive information enters Git history, simply deleting it from the latest file may not remove it from older commits.

---

Best Practices

• Write clear and meaningful commit messages.

• Use action verbs such as Add, Fix, Update, Remove, and Refactor.

• Keep commits small and focused.

• Create one commit for one logical change.

• Run git status before committing.

• Review staged changes.

• Never commit passwords or API keys.

• Commit regularly instead of waiting until the entire project is complete.

---

Useful Commit Commands

Command	Purpose
git commit	Create a commit using an editor
git commit -m "message"	Create a commit with a message
git commit -a -m "message"	Commit modified and deleted tracked files
git commit --amend -m "message"	Change the latest commit
git status	Check repository state
git diff --staged	Review staged changes

---

Summary

A Git commit is a permanent snapshot of staged project changes. The git commit command records those changes in the local repository and adds them to the project's history.

Every commit contains important information, including the project snapshot, author details, date, commit message, parent commit, and a unique Commit ID.

Good commit messages make project history easy to understand. Instead of writing vague messages such as "Update" or "Done," professional developers use clear messages such as "Add login validation" or "Fix payment calculation bug."

The most important rule is simple:

One commit should represent one logical change.

By creating small, focused commits with meaningful messages, you build a clean and professional Git history.