I'm not sure I follow your example exactly...
What works for me (and I am just one person, and - again - not really a professional developer) is that I think in terms of branches. If I want to add a new feature, step one is to create a new branch. I do whatever I want in there, make 1 commit or 50 commits, push to the repo 1 time or 50 times (note that sometimes I might want to push incomplete work so I can load the branch on multiple machines), test in a realistic but isolated environment, fix whatever bugs come up, and generally work however I want to work. Then I merge (or submit a merge request as the case may be) when I'm satisfied. And then I delete the branch, purge it from the repo, may it never be heard from again. If I got something wrong or want to change the work I just submitted, I start over with a new branch.
This is certainly not the only workflow, undoubtedly not the best workflow, and maybe not even a good workflow. And it probably breaks down if your changes are sufficiently complicated (though I avoid this by always working in bite-sized chunks, which I've learned to do the hard way). But it works for me and - as far as anyone on my team has ever told me - my colleagues and collaborators.
I can't comment on git's other features or alternative workflows - I rarely or never use them! But what I described is functional, simple, and covers 100% of the cases I've encountered in my (brief) career in software. And I think for 99% of users just getting started with git, if they just pick a simple workflow and don't fight the way git wants them to do it, they'd also find that git is surprisingly easy to learn and to use.