What should happen during a squash/rebase is that the semantic meaning of commits should be revised for maximum legibility of a future maintainer. If you did o

What should happen during a squash/rebase is that the semantic meaning of commits should be revised for maximum legibility of a future maintainer. If you did one "thing" on a PR branch, and it took you 10 commits to do it, those 10 should be squashed to one, and the commit message should be "Added thing." If you did 3 "things" on a PR branch, and it took you 10 commits, you should squash those 10 into 3 semantically meaningful commits: "Added Thing#1" "Added Thing#2" "Added Thing#3" This is doubly true if you ran into some complexity during the implementation that caused you to have to do the extra stuff -- that's exactly the type of detail someone looking back on commits needs to understand the development history. This is something that you are not allowed to do under most squash-merge policies, because "1 PR == 1 commit" for maximum legibility. Of course, nobody ever takes the time to do any of this which is how we ended up with such policies in the first place.