How to prevent losing data by using git in a destructive way

Description

Git is awesome. It's simple enough so almost everyone can understand the concept, but increases in complexity when you want to achieve advanced operations. In this case, Git can also be dangerous to your repository.

It's possible for example to delete a branch you are working on, rewrite history and lose it completely. And it's possible to remove files entirely from Git and its history as well, whereas those files shouldn't be deleted in the first place. Or use git push --force in a very destructive way.

While it's possible to recover in some cases thanks to dozens of hours spent reading Stack Overflow, it's also possible to put your project in a state that it becomes unrecoverable.

Can we brainstorm on what we could add to GitLab to prevent losing data by using git in a destructive way?

Proposal

This is a brainstorm at the moment. Some of these ideas are controversial.

• For MR that are pushed to master and contains commits that delete files on master, have a way to keep those files in the project (the "extended version history" from Dropbox)
• All branches that are deleted right now at the moment, could be physically deleted after 30 days instead.
• If you change the content of a file by more than 60% (or more), ask permission before merging.
• Only masters can submit commits that delete a file.