I was with you till this part >When I’m ready to present some or all of my changes to upstream, I grab git rebase and reorganize all of these into their respec

I was with you till this part >When I’m ready to present some or all of my changes to upstream, I grab git rebase and reorganize all of these into their respective features, bugfixes, and so on, forming a series of carefully organized, self-contained patchsets. That seems like a lot of extra work to "not use" branches. I do less work than that and don't use branches. I just tag the releases. Whenever I want a certain commit to triger CI/CD for build/testing and preprod deploy, I just tag a git commit as "release-[most recent git commit 8char fingerprint]" using a little script and some cli aliasing. Then push. Release is built, and I can keep pushing to master unfinished features. But because the working version is tagged, Ops can always rebuild, redeploy, or roll back to known good commits.