The fact that a) there even needs to be a golden rule, b) it's not obvious c) not everyone knows about it ... and I'm sure for many other reasons is a very strong reason to be spooked.
Git is like uranium, powerful, but so many don't even know what they are getting into.
Or maybe it's like C++ - really dangerous, but after a while, you learn to avoid most of the pitfalls and then it starts to feel 'ok' even though such pitfalls shouldn't exist in the first place ...
Rebasing onto a public branch and rebasing while on a public branch mean completely different things. The first happens all the time, the second creates problems for people doing the first.
Pardon my ignorance, but if you rebase while on master, are you not changing the master branch history for everyone? Isn't the point of the golden rule to not be re-writing the history of public branches?
Again it troubles me that even the language of Git is sometimes ambiguous.
I feel that there should not be a 'golden rule' of something that should never be done - it's a flaw in the product. It simply should not be possible, or at least not with someone without super-admin rights.
I feel Git is very much an administrative level tool, and that there should be something else for devs; something that is fairly obvious, consistent, encourages/forces the org. the policy and makes it so that devs don't have to think to much and really hard to screw up. Admins can give special privileges to the 'true experts' on an as-needed basis.
