To squash or not to squash
When reviewing a pull or merge request, tools like GitHub and GitHub offer the option to squash the commits before merging.
If the request had twenty commits, they'd be combined into a single commit before being merged.
But should you do it?
The answer will be "it depends" based on the project or team, but I'm personally not a fan of squashing commits.
Even though I commit small changes often, I put quite a bit of effort into crafting commits and writing detailed commit messages that capture the reason for each change. If the commits are squashed, either the messages will be combined into one extra-long commit message or I've seen them be deleted completely.
One large commit message would be very difficult to read and connect specific messages with their changes, and deleting the commit body would lose the history completely and waste the time it took to write the messages and craft the commits. It may be available within the pull or merge request page but there's no guarantee that you'll continue to use the same repository hosting service in the future.
One large commit would also be difficult to debug if there was an error. If the whole feature was added in a single commit, tools like git bisect would no longer work and a single commit couldn't be simply reverted if it contained a bug.
I prefer to keep the original small commits and instead prefer to use rebasing and only fast-forward merges to avoid merge commits and keep a simple, linear history in my Git log, and be able to easily read, find and, if needed, fix the code that's been committed.
- Oliver
P.S. If you're creating a new Drupal module, try my free Drupal module template.
