When you’re ready to solidify your changes in Git, you need to use git commit.

A commit is Git’s way of taking a snapshot of your project at a specific moment in time. It captures exactly what’s in the staging area and saves it into your repository’s history, along with a message that explains why the change was made.

In this chapter, we’ll look at how git commit works.

The Commit Process

When you run git commit, Git takes everything that’s currently staged (the changes you added with git add) and turns it into a new commit object. You can think of this as saving a new checkpoint in your project’s history.

That commit object contains three key pieces of information:

You can visualize this as a simple commit graph:

Here, each letter represents a commit. When you create a new commit, it points to the previous commit (C), creating a new state:

Here, D is the new commit you just created, and it points back to C as its parent. This linked structure is what allows Git to move through your history, compare different points in time, and let you rewind or branch your work safely.

Basic Usage of git commit

The simplest way to create a commit is by running:

The -m flag allows you to specify the commit message directly in the command line.

If you forget to stage files before committing, Git will remind you that there are no changes to commit. Remember, git commit only works with staged changes.

Example:

In this example, file.txt is staged for commit, and the commit message conveys the context of the changes made.

Commit Options and Flags

Git provides several options with git commit that enhance its functionality. Here are some of the most useful ones:

--amend

If you want to change the most recent commit (for example, to edit the commit message or add new changes), you can use the --amend flag:

This command will replace the last commit with a new one that includes both the previous changes and any new modifications staged.

--no-edit

If you want to amend the commit without changing its message, you can use:

This is useful for quickly adding changes to your last commit while keeping the original message intact.

--dry-run

Before committing, you might want to see what changes will be included without making any commits. Use the --dry-run option:

This allows you to verify your staged changes without altering any commit history.

Understanding Commit Objects

When you create a commit, Git doesn’t just save “some changes.” It creates a commit object with a well-defined structure.

Each commit object contains:

Together, these pieces allow Git to reconstruct how your project looked at any point in time and to support powerful features like branching, merging, and rebasing.

Exploring the .git Directory

All of this data lives inside the hidden .git directory at the root of your repository. Commit objects are stored there under filenames derived from their SHA-1 hashes.

If you’d like to inspect a commit “by hand,” you can use: git cat-file -p <commit_hash>

This command prints the raw contents of the commit object, including its tree reference, parent commit(s), and metadata. It’s a great way to see how Git actually represents the commits you work with every day.

Best Practices for Commits

To maintain a clean and efficient commit history, consider the following best practices:

By following these practices, you’ll create a commit history that is not only clean but also highly useful for collaboration and debugging.

In the next chapter, we will look at crafting commit messages that not only convey the purpose of your changes but also enhance the clarity and usability of your project history.