TL;DR: most dev teams should use Squash Commits instead of Merge Commits when merging single-feature/bugfix Pull Requests in a [[Git]] repository. ## Overview When teams are working in a Git repo using any form of feature-branching (whether short or longer lived), merges to the main branch can be done either as a "Merge Commit" or a "Squash Commit". Merge Commit is typically the default merge strategy in GitHub and BitBucket. It works by maintaining all the commits from the feature branch in the target branch, and adding another merge commit at the end, which includes the details of the PR in the commit description. However, the main problem with Merge Commits is that the Git commit log history becomes very messy and unhelpful to other devs. Some specific examples: - Overly granular or generic commit messages e.g. "fix broken test" - A load of "Merged develop into feature/my-lovely-feature" type messages when devs sync their branches ## Writing messages for squash commits When entering the message for the squash commit, you should use the title and number of the associated Pull Request. Developers should take care to provide their Pull Requests with clear and specific titles. Several popular hosted version control systems allow you to customise the default template used to prepopulate the squash commit message. ## Automating changelog creation If you want to produce a text changelog detailing all the changes since the last release, if you use a Squash Commit strategy, you should be able to use the Git commit messages as-is, since the commit messages are at the per-feature/fix level of granularity. ## When merge commits are still ok If your team is following a workflow such as GitFlow and has more than one long-lived branch (e.g. feature PRs go to a `develop` branch and then production releases go to a `main` branch), then you will want to keep the context of the individual commits in the source branch and then do a Merge Commit to the target branch.