> facilitates much better code review discussions Hmm, I usually mark PR’s as draft until ready for review, and then I expect the discussion to be about the cu

> facilitates much better code review discussions Hmm, I usually mark PR’s as draft until ready for review, and then I expect the discussion to be about the current state, not a previous intermediate state. Easiest with small PR’s. > enables use of git bisect to locate bugs Interesting. I know _of_ git bisect, but haven’t used it as part of my workflow. Have you found it useful to bisect commits on a feature branch (which, presumably, represents unfinished work)? > allows for informative commit messages associated with the changes I find using the PR title and accompanying info in GitHub or similar to be quite informative - that should convey the purpose of the change. > communicates clearly to future self about why changes were made See above. Perhaps we work differently, but I find it clearer to read a git history where each commit represents a single, complete feature/fix/refactor instead of intermediate steps.