Last Updated: January 3, 2026
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.
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.
In Git, a commit is made up of three main components:
When you split a commit, you modify the tree while maintaining the overall commit structure.
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.
To split a commit, we will use the interactive rebase feature. This allows modifying commits in your history.
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:
After splitting, your commit history will look different, with each logical change represented as a distinct commit.
Splitting commits is not just a theoretical exercise; it has practical implications in many scenarios:
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.
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.
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.
While splitting commits can be beneficial, there are pitfalls to watch out for:
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.
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.
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.