Carry on as planned and if you bork it all, switch to the backup branch which retains the original commits and all, delete the borked one and have another go
I have a custom bash function named "backup_branch" that does exactly that, along with "restore_backup" and "delete_backups". It's made my life 10x simpler.
Assuming this is the reflog, this is not true. Because the working copy doesn't get snapshotted, it is relatively easy to lose uncommitted data. I've spent much of my professional career working on source control and even I've lost uncommitted data a few times.
Dropbox doesn't have a notion of uncommitted data. Why should source control?
As long as you commit everything, yes. The reflog is the safety rope of git. Everyone who isn't confident with the reflog should go and learn it right now.
Pick your most important repo. Make sure everything is committed. Doing something stupid like `git reset --hard HEAD~100`. Look how fucked your work is. Do `git reset --hard HEAD@{1}`. Look at how nothing was lost.
Yep, and even the more powerful fixup workflow where you can essentially amend commits other than HEAD. I do it via git-autofixup: https://github.com/torbiak/git-autofixup
Either way, even simpler, imho, than any log that one has to comb through after the fact is to create a named backup
Carry on as planned and if you bork it all, switch to the backup branch which retains the original commits and all, delete the borked one and have another go