I've read a fair number of the top level comments and I don't see anyone who develops like me, so I'll throw my hat into the ring. I'll start by saying that I'v

I've read a fair number of the top level comments and I don't see anyone who develops like me, so I'll throw my hat into the ring. I'll start by saying that I've always worked at companies where the norm is trunk-based development, where the norm is to develop small changes (< 500loc, typically < 100loc), get them reviewed, and land them as a single commit with a nice message on the tip of the trunk branch. The way I build these commits is to check out the main branch and start coding. As I write code/tests/documentation I start staging (git add) and committing (git commit) into a single commit. Subsequent commits are "git commit --amend". When I commit I usually update the commit message with any details about the stuff I'm adding. Changes in the commit I'm pretty sure are going to be in the CR, staged changes I'm not sure about, and unstaged changes are "what I'm working on now". This way, "git diff" shows me what I'm working now (in case I'm interrupted) and "git show" shows me what I'm ready to push. If I want to sync with the trunk, I can do "git stash && git rebase && git stash pop", which mostly works well though sometimes there are merge conflicts that need resolving. When I'm ready for review, I rebase my single commit, rerun any tests, do a git show and review the change top to bottom, then create the code review. Then I review the change again in the code review tool, where I quite frequently find silly things I missed like typos in documentation of print statements I forgot to remove. Then add reviewers. The only downside to this I have is when I want to back out changes I've already committed. Git doesn't give you a great way to do this, but I've written an alias that can remove all changes to a file from the commit at the tip of the branch. I use this a couple of times a year.