I don't understand this. You do not back up your code to any shared repository while still working on a feature? What if it takes 2+ weeks? You have 2 weeks of code replicated only locally on your laptop? Or what do you mean by local?
It doesn't matter what source control system you hand me. It could be your ideally perfect system. I would still rewrite history that I'm not collaborating with others on. I try treat source history (as much as is practical) as a sequence of logical changes to the code. I treat it like I treat the code. I try to optimize for making it intelligible and understandable to other humans (including myself).
You can look at any of my projects on GitHub for examples.
If a person commits a lot, they can end with all kinds of little commits which are just fixing typos or syntax errors, exploring half-baked ideas, can't be bothered writing a commit message right now, etc. What's the point of keeping all that stuff long-term?
Then, when it is ready to be reviewed, you rewrite that real history into something more logical - e.g. first commit creates an interface, second commit implements it, third makes other parts of the code call it, etc - and then submit that for review as a PR - that "fake" history is likely to be much more useful to others (and to one's own future self) than the real development history was
back when I used hg small commits were not a problem as the branch name remained after the merge and so mostly we were able to treat branch names as the squashed whiae still having acces to the typo commit if needed.
I don’t think the real issue is Git’s features. Even if Git had whatever additional features you wish it had, it still doesn’t change the fact that a history of typos and stupid mistakes isn’t very useful to anybody (especially in the long-run), and hence there is little or no value in preserving it; while a faked history which breaks the change down into logical steps does have some real long-term value, in terms of helping anyone who needs to review and understand the change in the future
So I think what people are saying (and I largely agree with them) is that it's fine to rewrite history as long as you never share the ugly mess that existed before the rewrite with others.
A typical example of this is having un-shared ("local" - but could be backed up) streams of "tweak a comment, fix a semicolon, xxx" changesets that aren't really going to be useful to other people. Before you share with others, you squash them down to a single (or few) "implement feature X" kind of changes, often with linear history.
Having that less-branchy and less-noisy linear history available is useful in the future when you want to examine the history of the repo. Future people don't need to know that you fixed a comment, added a semicolon, etc. They want to know the big coherent logical changes that were applied to the repo.
Squasing/rebasing/fixing history before you share it allows you to have your cake and eat it too, more or less.
----
EDIT: Here's a decent email from Torvalds on the subject (not that I agree w/him about everything, but in this case): https://www.mail-archive.com/dri-devel@lists.sourceforge.net...
If the project is too large for this, you can also fork off the repo itself and then merge in your changes to the main canonical version when you're ready.
> to any shared repository while still working on a feature? What if it takes 2+ weeks?
A lot of projects don't want our partially implemented changes, if only one person is working on them, just the first ready-for-others result and subsequent smaller fix updates.
> Or what do you mean by local?
This is key: remember that git is distributed, so backups of your really local repository should be as easy as pushing to a remote copy. If you aren't doing that (or even if you are) keeping an automatic off-machine backup of your working directories is a good idea in case of drive failure.
If you are working on a feature with a team, perhaps a team-local shared repository is a valid answer.
And to answer your actual questions. Yes, you either:
1. Push it to a shared repo but with a name that makes clear it is a branch belonging to you (e.g. `<yourname>/branch`), or
2. Back it up with your standard laptop backup (the one you have set up that backs up non Git stuff too).
Basically it's the equivalent of bringing patches up to date before upstreaming them. Upstream isn't going to apply a patch that no longer applies cleanly.
Local != not pushed to a remote. You can totally push to a per-developer remote, or to branches under a per-developer namespace.