Should I squash small, development commits into bigger ones?
commit, dvcs, squash
Solution
Reasons for squashing commits:
- A cleaner, simpler history.
- A smaller history. Less baggage when cloning repos.
- Removes "junk" commits, such as typo fixes.
- Gives the opportunity to improve commit messages.
Reasons against squashing commits:
- We can no longer follow the history of that feature/bugfix in order to learn how it was developed or see alternative solutions that were attempted but later replaced. (Cited from Mike Gerwitz's A Git Horror Story.)
- It renders git bisect useless. If we find a bug in the software that was introduced by a single patch consisting of 300 squashed commits, we are left to dig through the code and debug ourselves, rather than having Git possibly figure out the problem for us. (Cited from Mike Gerwitz's A Git Horror Story.)
Please feel free to add other reasons to this wiki answer, if you don't want to give your own answer.
Problem
There are (too) many questions regarding how to squash commits for git and other DVCS, such as: - Squash my last X commits together using Git - How to squash all git commits into one? - Joining various commits in one without merging - Is there a way to squash a number of commits non-interactively? - Can I squash commits in Mercurial? - With Mercurial, how can I "compress" a series of changesets into one before pushing? - ... My question is, do I want to squash commits? Should I keep the detailed sequence of commits showing how a feature was developed, or should I rather squash them into one once the feature is finished, to keep the history cleaner?
Related problems
- With Mercurial, how can I "compress" a series of changesets into one before pushing?
- How to squash all git commits into one?
- Can I squash commits in Mercurial?
- How do I squash my last N commits together?
- Is there a way to squash a number of commits non-interactively?
- Joining various commits in one without merging