Personally I just use git for that. Even if I'm not 100% happy with some solution, I put it into a commit and then do subsequent improvements, or just remove it again entirely.
Cleaning up your history isn't hard if you think about building a clean-up-able history from the start, where each commit is a unit. At least it is easy for me. If it's larger and complicated, I create branchname-v1, branchname-v2, etc. branches and squash. Those branches will still hang around in my fork of the repo should anyone need them.
As for my personal projects, I recently realized that using leveldb wasn't going to cut it for me right before I finished the database storage feature. I still finished it to create a commit that didn't break the build and then worked on switching to rocksdb. If in the future I decide to switch back to leveldb, it's always there.
Not as annoying as learning to navigate some IDE-specific way of doing it. And I usually end up cleaning up my commits, anyway. Also, if I've committed things, then I have commit hashes to refer to in my notes.
this is indeed useful, but what the parent comment is referring to is it also stores with local history outside of git. So you can check both git history for a selection, as well as local history that exists since your last commit.
I use my editor's history heavily, but never needed something beyond the Ctrl + Z / Ctrl + Shift + Z history to access things done immediately prior. If I'm unsure if I'll need some approach in the future, I make a commit. I've become increasingly good at this prediction.
