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
- stash my working branch's uncommitted changes,
- switch to main,
- pull down new changes,
- make the new branch,
- make the actual change,
- commit the change,
- push the branch,
- open PR,
- switch back to my working branch, and
- 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.
