
It's much easier to read through a source tree and understand what bugs have been fixed when a single commit fixes a single bug, for example.


Pick cc4f2b5 Didn't work, trying something else For our example above we'd see a text editor with the last 4 commits in reverse order, like the following: pick b1339db Fixed issue #421 The -i flag is short for -interactive, which will bring up your default text editor so you can edit the commands before rebasing. This tells Git to re-apply the last 4 commits on top of another base tip. In order to squash the commits you'll need to use the rebase command like this: $ git rebase -i HEAD~4 In cases like this you may want to squash commits together to create one nice, clean commit for this issue. All they really care about is the final solution to issue #421, but not necessarily how you got there. Although it's great the solution was eventually found, this isn't exactly something you'd want to share with the rest of your team. For example, let's say your recent commit history looks something like this: $ git log -onelineĬc4f2b5 Didn't work, trying something elseĪs you can see from the logs, issue #421 took a few tries to get fixed.

This can be done for many reasons, one of which being that the source history needs to be cleaned up before sharing with your team or submitting a pull request to an open source project. When you squash commits, you're combining 2 or more commits into a single commit. In this case I'm referring to cleaning up the history of a source tree by squashing commits. One of the nice things about Git is its flexibility, allowing you to perform just about any task on a source tree that you'd need.
