Having logical commits are a nice-to-have IMO, but I wouldn't be so strict. An oops commit here or there doesn't necessarily throw off one's understanding of t

Having logical commits are a nice-to-have IMO, but I wouldn't be so strict. An oops commit here or there doesn't necessarily throw off one's understanding of the history of what a particular group of commits is intended to do, and there isn't necessarily anything wrong with an oops commit; it's correcting an issue in a previous commit. Besides, it's more common to look at a PR as a whole rather than as individual commits. I know that sometimes you do, but at that point "oops" commits are rather trivial to look at. What's more important is that the commit history of the main branch remain sane. That's why you might want to squash-merge, since it mostly solves the issue of having too many extraneously-named commits in a place where one indeed may want to examine individual commits. Honestly, I couldn't give less of a crap what sort of commits someone has on their branch as long as it's not so many that I can't possibly review all of the code. Don't get me wrong, because I think it's great if you want to maintain that sort of standard in your own work. I don't find it particularly reasonable to expect this of anyone else because it's more of an aesthetic choice than a practical one, not that either are exclusive of the other in this case. > Preferably no merges from the parent branch. Yes. Always rebase. Rebase frequently.