For example, how often do you use "staging" (as in not git add .) and how efficient is it's use?
In my workflow, you need a feature - you develop, you build, it works, you commit.
Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug.
You fix it. Now you need to commit in two batches, the new feature and the bug.
This is the commonly given reason for the add/commit/push workflow.
But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)
What? I'd stash the changes I'm working on for the new feature, cut a fresh branch from whatever trunk/master/develop we're using, fix bug, checkout my other branch again, stash pop/apply, and we're back to where we were 10 minutes ago (or 5 days, if that's how long the bug-fix took).
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.
I use it frequently. Even if I'm only using add ., I check the staging area before I commit.
Reverting wouldn't be faster and wouldn't separate out files that are meant to be committed from those that aren't. It's also harder once you've pushed. So staging is more efficient as well.
I used both cvs and subversion for many years. They have their own complexities, but lack git's ability to manage them.
In my workflow, you need a feature - you develop, you build, it works, you commit.
Because think about it like this, you need a feature. You build, it works, then before committing you notice a bug.
You fix it. Now you need to commit in two batches, the new feature and the bug.
This is the commonly given reason for the add/commit/push workflow.
But at some point it's probably faster to either revert, fix bug, then merge with main than to make your staging precise (especially you don't play with staging in your IDE where you can test code as you type)