AlgoMaster Logo

Splitting Commits

Last Updated: January 3, 2026

6 min read

When working with Git, committing changes is a fundamental part of the development process. However, as projects evolve, you may find that your commits need refinement. Perhaps a commit is too large, or it contains unrelated changes. This is where splitting commits comes into play.

By breaking down a commit into smaller, more focused commits, you create a clearer project history. This not only aids in understanding the evolution of the codebase but also makes it easier for others to review your work. Let’s dive into how to effectively split commits and the implications of doing so.

Understanding Commit Splitting

When we talk about splitting commits, we're essentially breaking a single commit into multiple smaller commits. This can enhance clarity and maintainability in your project's history.

Why Split Commits?

  • Clarity: Smaller commits can represent distinct logical changes. When someone looks back at the commit history, they can quickly see what each change accomplished.
  • Easier Reviews: Code reviews can be more manageable with smaller, focused commits. Reviewers can assess each change without being overwhelmed.
  • Reverting Changes: If a bug is introduced, it's easier to revert a smaller commit rather than dealing with a large one containing multiple changes.

Commit Structure

In Git, a commit is made up of three main components:

  • Tree: Represents the snapshot of your files at the point of the commit.
  • Parent: Points to the previous commit, creating a history.
  • Metadata: Includes the author, timestamp, and commit message.

When you split a commit, you modify the tree while maintaining the overall commit structure.

Preparing to Split a Commit

Before you split a commit, ensure your working directory is clean. This means you should have no uncommitted changes. You can check the status with:

If you have uncommitted changes, either commit them or stash them using:

Next, identify the commit you want to split. Use the git log command to find the commit hash.

Once you’ve identified the commit, you’re ready to start splitting it.

The Splitting Process

To split a commit, we will use the interactive rebase feature. This allows modifying commits in your history.

Step-by-Step Guide

Start an Interactive Rebase: Begin by starting an interactive rebase from the commit before the one you want to split. For example, if you want to split the last commit:

Edit the Commit: In the editor that opens up, identify the commit you want to split and change the word pick to edit. Save and close the editor.

Reset the Commit: Once you enter the rebase environment, Git pauses at your commit. You now need to reset it to the state just before the commit:

This command undoes the commit but keeps your changes in the working directory.

Stage Changes: Now, you can selectively stage the changes you want in the first new commit. Use git add for specific files or lines. For example:

Create New Commits: After staging your changes, create a new commit:

Repeat the staging and committing process for the remaining changes. After staging the next set, run:

Complete the Rebase: Once you have committed all changes, finish the rebase:

Visualizing the Commit Changes

After splitting, your commit history will look different, with each logical change represented as a distinct commit.

Real-World Applications of Splitting Commits

Splitting commits is not just a theoretical exercise; it has practical implications in many scenarios:

Bug Fixes

Imagine you worked on a feature and made a commit that included a bug fix as well as a new feature. By splitting the commit, you can separately address the bug fix, allowing for an immediate rollback if necessary.

Code Refactoring

Suppose you refactor multiple methods in one commit. After realizing that your changes need to be more granular, you can split them into smaller commits, each focusing on a single method. This way, future readers can easily follow the evolution of each method.

Feature Branches

When working on a feature branch, you may find that you have mixed changes. Splitting commits can help you prepare the branch for a pull request, making it easier for team members to review your changes.

Common Pitfalls and Nuances

While splitting commits can be beneficial, there are pitfalls to watch out for:

Forgetting Unstaged Changes

If you have unstaged changes in your working directory before starting the split, Git may include them in the split commit unintentionally. Always ensure your working directory is clean.

Large Commits

If your commit contains too many changes, the process of splitting can become cumbersome. It's advisable to split large commits as you make them, rather than waiting until they become unwieldy.

Preserving Context

When splitting, it's essential to maintain the context of the changes. Ensure that related changes are kept together in the same commit to avoid confusion in the future.