Actually, this solution is not restricted to main, as it works for any branch.

Regarding push --force, just be aware of the risks before you do it.

Good points. I wonder if there's any way to avoid the force pushing after using reset?

If the previous commits (the ones that got lost after reset) were already pushed, you can't avoid a forced push.

The only way to avoid it, AFAIK, is to not rewrite history that's already pushed (don't rebase/reset if it affects already-pushed commits). Instead, you could revert the commits, preserving history (example), which eliminates the need to force-push.

You could also go to the server and do there the same, that would avoid the need for a forced push.

H_H‭ This doesn't eliminate the problem. Let's suppose the remote has 3 commits:

A <-- B <-- C (main)

And suppose that lots of people already pulled it (so they all have the 3 commits in their local repos).

If I reset main to commit A (either by force push or directly in the server), the remote will be like this:

A (main)

Commits B and C are lost (they're not part of main branch's history anymore). And anyone who tries to pull from this remote will have divergent histories, and will struggle to fix their local repos (imagine, for example, if someone is working on a local branch created from B or C).

The problem is not the forced push, but the consequences for anyone who still has the affected commits locally (and the problem will be the same if you do it in the server directly).

The problem is not the forced push

Iizuki‭ asked to avoid the forced push. That is sometimes possible. That was the only thing i addressed. If it solves any problem or not is a different story.

H_H‭ You suggested an alternative that leads to the same problem, I just thought this was worth mentioning (not only for you, but for any future readers).

Otherwise, one could read this and think that your solution would avoid the problems caused by a forced push (which is not the case).