All Articles

Articles tagged with Development Practices


Why Squashing commits is bad

I recently had a discussion with a colleague about why squashing commits in Git pull requests, or any source control for that matter, was bad. The discussion was started with a suggestion that developers (at work) should start to follow a specific commit message format. This was so that release notes could be automatically generated based on the commits in a given release. Now to do this, and have a release note that looks sensible, it relies on very few commits per feature or bug fix, which in turn involves squashing developer's commits. While I don't object to a standardised commit message and automated release notes (in fact I'm a massive supporter of devops and build/task automation), I believe that squashing commits is a bad idea. Here's why.


Keeping 'CI' feedback time low by putting developer builds first

More and more people are now adopting some kind of Continuous Integration system, where their full suite of tests and checks are run on every commit with the aim of giving fast feedback to developers. As this adoption grows, and more and more tools come out to help with it, feedback time for developers can actually increase rather than decrease.