Do I need to disable git push origin master -f at the repository level?

Question

git

There was a heated discussion in my team about whether pushes to masters with the force key should be prohibited at the repository level.
Our production process is as follows. When the developer takes another task for himself, he creates a separate branch for himself, which is recaptured from the current master. As soon as the task is completed, we need to create a merge request, which should be reviewed by someone from the team. If everything is in order, then the branch is merged with the master and deleted. We use gitlab, which allows you to merge the branch with the master in one click.
Once a branch got into the master, which should not be there yet. It so happened that there was a merge request to which there were comments, but the person who looked at the code clicked in the wrong place and merged the unfinished branch with the master. A revert was immediately made, which is essentially a commit that destroys the previous merge. This very revert provoked a couple of problems. As a result, the following was done - this very random merge was "cut out", after which the terrible command followed git push origin master --force-with-lease.
In my opinion, this decision was justified because:

1. There will be no garbage in the version history. Indeed - merge just entered by negligence, a reverse commit fell on top of it. But in an hour, as soon as the things that appeared after the review are implemented, another merge will be made with the only difference that it will be a few more commits. As a result, we have a bunch of unnecessary code in the history.
   
2. In our particular case, if you do not cut out the unsuccessful merge, then in the end, after the implementation of the comments, you would have to rebase to the current master (which already had a reverse commit) and this would create a bunch of conflicts that would have to be unleashed.
   

In my opinion, this decision was more than justified, nevertheless, a holivar began.
Questions:

1. Who thinks - is it necessary to disable the possibility of push'a with force?
   
2. What do you do if something accidentally gets into the master that should not be there?
   

Answer 1

1. History rewriting is needed, but it must be used carefully. Pushing with a force to the master is an exception to the rule, and in your situation it is completely justified.
2. In 99% of cases, revert saves. In other cases - push --force, but this is extremely rare.
In general, I am a fan of rebases, so that the history of the git is linear. If the feature branch is not fast forward, then rebase to the master and rewrite the history of this branch. Well, then fast-forward merge (or even better - squash the commits before that). But there may be disagreements, so I use those options that are accepted in the team.

Answer 2

In my opinion, development should be carried out in the develop branch (oddly enough). Thus, the only way for code to get into master is to merge the current develop into master.
Thus, in master there will always be a ready, working, polished release, while the current development is carried out in develop.
As for the question
1. it’s good to prohibit direct push to master, but when force majeure arises and you need to urgently roll something in, you’ll climb one hell of a way to turn on the push option)
2. they do a revert, what else to do)

Answer 3

The history of commits is what history is for, to display all changes in chronological order.
Git push should be prohibited, in essence it is a sword of Domocles, only over the heads of the entire team.
Several times I met forced pushes after an unsuccessful rebase. Once for a colleague, I had to restore a 2-week history, not the most pleasant experience.
revert + comment in the bug tracker about the reason for the revert.
On the last project, releases were 1 time in the morning and optionally in the afternoon. The release was carried out in a semi-automatic mode, the branches were pulled from the bug tracker, and then poked at the master. In case of conflict - automatic revert. In the event of a breakdown of the assembly - manual search for the culprit and manual reverse.
Forced push is not needed. The rebase did not take root.
Yes, there were fakups, for this there were optional releases during the day, so that the author, having seen his cant on the sale, could fix it asap on the same day.