Rebasing has a simple rule: it is perfectly fine as long as you haven't shared those commits.*

Perhaps git should have a "checked rebase" command that requires a `--force` flag if there's an upstream branch set.

*And even then it's kind of okay as long as no one else has made commits on top of the rebased commits.

It's also very wise to make sure you disallow force pushing to master/main/production. If you force push to a topic branch, it's usually ok. If you accidentally overwrite someone's changes, it's because you are working together and you can communicate that you messed up and for them to `pull --rebase` or however you want to resolve it. Usually that is. There's always room for disaster :)

> Usually that is. There's always room for disaster :)

For me, this is where the problem with got lies. I use so many of it's commands infrequently enough that I don't know where the weird disastrous edge cases are, where I should use.

I think git would greatly benefit from a topical man page; a list of common and uncommon situations that shows the recommended commands for solving them, and explains what those commands do. I know that hundreds of random "guides" exist, but are they outdated, are they cannon, do they have bugs? When your UI is esoteric, situational documentation is really important.

Ya, the git UI is not great. It has improved a ton over the years but still not great. Have you ever seen Git Koans? It's good for a laugh. https://stevelosh.com/blog/2013/04/git-koans/

--force-with-lease

Which BTW I learned it exists when magit switched "p -f u" to use it instead of plain --force.

Oh right. I always neglect to do that mostly out of laziness of typing it out on the command line. It's funny, though, I maintain a branch plugin for vim (it's a fugitive extension) and I recently accepted a PR to switch `--force` to `--force-with-lease` yet I still don't do it. I need to start doing it!