This will largely depend on your workflow, but in a PR-based workflow, I've for a while now held the opinion that individual commit messages are useless to me i

This will largely depend on your workflow, but in a PR-based workflow, I've for a while now held the opinion that individual commit messages are useless to me in the history of the code, and that a squash with a final description + summary is the best way to go. There'll be cases where the following don't match, so let me explain what this is based on: - In our flow, a PR is small and is the unit of work that is guaranteed to compile/work (tested against master before merge) - Each individual commit inside the PR can be helpful for a reviewer, but the code should stand on its own and your commits (inside the PR) should not be a source of documentation - I have never been able to pick out a commit at random from non-squashed PRs, and be sure it will compile. Unless you're running CI locally before committing, you simply do not know - Spending a ton of time to create a nice history inside a PR is a waste of time, since throughout review or experimentation you will need to adjust work that you previously committed as if you had everything thought out - the alternative is aggressive history rewriting and force pushing which is very quickly a huge mess - Finally, it tremendously lowers the bar of what's required from each developer, which scales much better, when all you have to do is take extra care in the final title and description Now, most importantly, squashing PRs is tremendously helpful when digging around the code and having something like Gitlens explaining the changes: - Commits from a merge commit are on average a lie of the final reason, and very often something like adjusting formatting, fixing linting, which makes the original reason disappear as this was the latest change - Viewing the squashed PR title and description gives me so much more information and if I want to dive into the specifics, the PR itself is worth so much more than any individual commit message will be Again, this is something that fits with a specific workflow. If you're developing directly against master or similar styles, then obviously this won't suit you. --- The review and history part is actually something that is interesting to dive into for the importance of commit messages and what you and your teams expectations are. I'd recommend explicitly talking about this with your team :)