I’ve worked on multiple codebases where nobody on the team had been there when the sausage was first made. The squash commits are some of the worst commits for finding out why a weird design decision was made because all the things that came out in code review or would have had bugfix commit messages in their local branch are all squashed together in one commit. CRs help a lot but frankly I do want to know how the sausage was made when I’m look through the git history or else I would just look at the code directly. Especially when I’m investigating some bug in prod.
I don’t quite understand what you mean. As I wrote I write my PR message as the commit message. That is one thing that is also very important for me. Write in the commit message why something changed. If the PR gets so damn big that it is so much to explain everything than it’s quite frankly too big. From
my experience the follow up commits for fixes or code review changes boil down to messages like “fix stupid bug”, “adjustments after code review”, etc. which are also not helpful when looking for the why. But I honestly understand what you mean. I’m just saying that limiting down the number of commits and the size of changes in them helped me over the years. I also don’t do it when I start of from a white paper. Only when the project enters the stage when PRs plus checks help mitigate potential bugs etc.
