It really depends on how the repo is set up and how much of the history you want to keep.
You can delete the commit by using this and deleting the line with the commit you don't want. This could also mess up histories of other people. People usually don't know git well enough to do git reset --hard origin/main so I'd not recommend it.
git rebase HEAD^1 -i # do stuff git push origin main -f # absolutely playing with fire here
On PRs there's a revert button that creates as revert PR to undo all the changes in that PR which is pretty useful. It has a downside where if you want to push the same changes again, just fixed instead of broken, you'll have to put them all back in again, revert the revert, delete both and merge again or reimplement the changes by using a combo of git checkout branch-with-changes, git reset --soft branch-without-changes, git stash, git checkout main, git checkout second-try and git stash pop`.
Currently on my team we're doing reverts with the Github gui, then reverting the revert and cancelling the CI/CD manually. This leaves the main broken but since we deploy on "production" it's fine.