Never having uncommitted changes

The other day I was commenting on how quickly a collegue seems to be able to create a new PR for a change. For me I need to

  1. stash my working branch's uncommitted changes, 
  2. switch to main, 
  3. pull down new changes,
  4. make the new branch, 
  5. make the actual change, 
  6. commit the change,
  7. push the branch, 
  8. open PR,
  9. switch back to my working branch, and 
  10. un-stash the uncommitted changes. 

He said, in effect, "I never have uncommitted changes." He also mentioned heavy reuse of his command line history, and I know of his highly customized git config [*]. But it was the idea of never having uncommitted changes that struck me. I think I have finally figured out that I should always be making small, tactical commits rather than waiting for a semantic commit. Then, when ready for the PR, use rebase not just for small reorganizations, but for wholesale reorganization into semantic commits.

* My use of IntelliJ for most git operations precludes these efficiencies.