But if it never appeared in the main branch then it doesn't really matter, does it? You don't want to clutter up the history with experiments and false starts.
Weirdly: yes, I do. It's handy, and those experiments show what I've done to tackle a problem. Numerous times those experiements that I've left in the repo somewhere have come in handy.
Hell, we keep our feature branches around here. *shrugs
I'm not sure that you don't. Having a history of how you got to the current version could help future maintainers understand why you made the decisions you did, and prevent them from making similar mistakes.
I tend to work out of a private branch, and commit early and often. So I end up with a lot of commits that say "fixed foo to be 1", then "oops, I meant it to be 2", then "No, it should be -7", etc. I'll drop a tag, then rebase a group of commits to re-order them (so all the fix, to a fix, to a typo mistake that shouldn't have been there) are together. Then sometimes I'll drop another tag, then squash, then rebase onto the main branch. Those temporary tags then get pushed only to a separate repo that only I write to (the one that everyone else uses gets the cleaned-up presentable code).
Well, I definitely prefer the rebasing route, but with the caveat that everyone's working on the same branch, so there's not much divergence. The only rebasing occurs when somebody commits before you do, and it's only your own local commits that need conflict resolution.
That seems like a git anti-pattern. On the other hand, one or two repos where I work have developed some, uh, interesting network graphs, as various branches have merged and evolved.
I suppose (s)he means that, if you squash commits, you lose the intermediate states containing code that was later deleted. It's not necessarily bad - squashing is a useful tool to clean up your changes before you merge them in.
Of course this leads to nasty conflict resolutions, so they solve that by squashing all of their commits before rebasing.
Now your code is no longer in the repo.