You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone else needs to be able to pick up your code if you get hit by a bus tomorrow? Because your boss or coworkers might need to be able to look at your code in an emergency? There are a million reasons to push that don't imply every commit on every pushed branch being suitable for splitting into another branch...
> Did you read your own link? The last paragraph says exactly what I've been saying.
It says that because they're (a) assuming if you've pushed code then you've probably published, which is a safer assumption but exactly what I've been arguing is not necessarily the case (and I've been trying to explain when it's not), and more generally (b) because they're erring on the side of caution. Which makes sense; I'd give the same advice to someone who's learning git. That's is exactly why the previous paragraph says "hopefully you’ll see that it’s not that simple" and "it’s up to you to decide which one is best for your particular situation". Those sentences aren't there for decoration. And it's why there is such a thing called a rebase workflow and why they made --force-with-lease and... again, I can't hope to convince you of the value of this workflow, just like how I can't convince you to use tabs over spaces (or tabs and spaces...). What I was doing was explaining how/when it can be useful while avoiding the problems you're hoping to avoid if you haven't already dogmatically rejected the rebase workflow from the start.
