In this lesson, you will learn how to decompose monolithic, "do-it-all" commits into a series of smaller, logically focused changes to improve your project's history and auditability.
Why Split Commits?
When you spend hours in a "flow state," it is easy to accidentally bundle a database migration, a UI tweak, and a bug fix into a single massive commit. While convenient for you in the moment, this creates a nightmare for reviewers. If a bug is later discovered, it becomes nearly impossible to use git bisect to isolate the problematic change. By splitting large commits, you create a "narrative" in your commit history that is easy for future developers to follow.
The Interactive Rebase Strategy
The most powerful way to split a commit that has already been made is through an interactive rebase.
- Start an interactive rebase targeting the commit before the one you want to split:
git rebase -i HEAD~n(wherenis the number of commits back). - Find the line representing your large commit and change the command from
picktoedit. - Save and close your editor. Git will pause at that commit.
- "Unstage" all changes from that commit:
git reset HEAD^ - Now, you are at a point where your changes are unstaged but still in your working directory. You can now selectively stage parts of your code:
git add -p - Commit the first chunk:
git commit -m "Refactor database schema" - Repeat the staging and committing process for the remaining parts of that original work.
- Once you are finished splitting, run
git rebase --continue.
By doing this, your single "mega-commit" is replaced by a sequence of precise, atomic commits. This makes your pull requests much easier to review because each commit represents a single, verifiable thought, rather than a disorganized "dump" of code. This practice is the hallmark of a senior-level developer who respects the time and cognitive load of their teammates.
Key Takeaway: Splitting large commits transforms a chaotic history into a clear, logical story, enabling faster code reviews and precise debugging.