The problem with rebase is it creates a lot of friction when sharing with others. Even if a single dev has two checkouts, it can get confusing ("can I just pull the changes or do I need to reset the branch? - dammit what did I do again? I guess I'll have to review both checkouts history in detail"). Merge based git push / git pull in the other hand, have none of this, thus conceptually much simpler.
Furthermore, since pushes must necessarily overwrite (--force), you actually risk loosing work.
This is all fine and doable but you have to be "on the ball" / paying close attention all the time thus introducing higher cognitive load.
The bottom line is getting work done and making history look good are competing objectives to some extent. There are all kinds of reasons to commit code (I got something working, I want to share something, I need to try this on another machine, etc.). Thus, the only way for commits to appear logical / atomic is to review the current state and refactor it to a logical looking but artificial series of commits. I can't imagine such efforts being useful enough to actually do in most cases. Perhaps even a task better suited to AI.
In reality, the PR is the only commit that anyone cares about. Everything else is mostly just noise. Therefore it would be best if the PR was a first class concept in git vs something only available outside of it (i.e. github).
What is your definition of a shared branch? Is it shared the moment you push it (assuming a github like workflow). Is it shared if you check it out on two separate machines just for yourself?
My definition of a shared branch is the one where only one person is working. It can be your local branch and the same one after you push it to remote. It's still not shared in the sense that only 1 person is supposed to work on that branch.
In this case, you can easily perform rebase and run `git push origin HEAD --force-with-lease` without causing any headache for anyone else.
Say you have a checkout on Linux and one on Windows and need to do some bespoke development work on each. I personally would just do git push / pull to avoid any potential for lost work. Maybe after the work is done, I would refactor the commits and rebase them before pushing to the authoritative server (e.g. github, azure dev ops, etc.).
Furthermore, since pushes must necessarily overwrite (--force), you actually risk loosing work.
This is all fine and doable but you have to be "on the ball" / paying close attention all the time thus introducing higher cognitive load.
The bottom line is getting work done and making history look good are competing objectives to some extent. There are all kinds of reasons to commit code (I got something working, I want to share something, I need to try this on another machine, etc.). Thus, the only way for commits to appear logical / atomic is to review the current state and refactor it to a logical looking but artificial series of commits. I can't imagine such efforts being useful enough to actually do in most cases. Perhaps even a task better suited to AI.
In reality, the PR is the only commit that anyone cares about. Everything else is mostly just noise. Therefore it would be best if the PR was a first class concept in git vs something only available outside of it (i.e. github).