You can revert individual commits with:

git revert <commit_hash>

This will create a new commit which reverts the changes of the commit you specified. Note that it only reverts that specific commit, and not commits that come after that. If you want to revert a range of commits, you can do it like this:

git revert <oldest_commit_hash>..<latest_commit_hash>

It reverts all the commits after <oldest_commit_hash> up to and including <latest_commit_hash>. Some versions of git also revert the <oldest_commit_hash> itself, so double check if that commit gets reverted or not. You can always drop the latest revert commit (which reverts the oldest commit) with g reset --hard HEAD~.

To find out the hash of the commit(s) you can use git log.

Look at the git-revert man page for more information about the git revert command. Also, look at this answer for more information about reverting commits.

Extra note for re-applying reverted commits:

Usually you revert commits because you discovered the commits that you pushed turn out to have an issue. Then you first want to restore the repo to a stable state, before you continue to fix the issue. So then you would first do the git revert, as described before. Then push those revert commits, so the remote is stable. After that you would want to re-apply the reverted commits locally, so your local repo's files are back to the state before the revert. Then you can fix the issue.

To re-apply the reverted commits, you have to revert the revert commits. So what you would do, is to again execute the git revert command, but then with the range of commits of the revert commits. So your new revert commits will revert the previous revert commits. Then your files are back to the state before the first revert. Then you can fix the issue, create a new commit with the fix, and then push all the new commits.

Git commit only saves it to the stage, which is locally on your computer. Use Push to update it to a remote server (Like github).

Use git revert <ID> to revert back to a previous commit. each commit has an identifying code.

See here for more details on revert

When trying to revert to a previous commit (for instance 123abc) ...

The emphasis I added here on the preposition "to", as in revert to, is crucial. The accepted answer at your linked question (How do I revert a Git repository to a previous commit?) calls this out:

This depends a lot on what you mean by "revert".

Running git revert on a single commit may not suffice. See the answers there about reverting multiple commits, if needed.

Running git reset --hard may suffice, but introduces the very problem you've encountered. The things to understand here are:

1. A branch name simply lets Git find one particular commit. We say that the branch name points to the commit. Using git reset, we can change the one particular commit to which some branch name points. Nothing else happens in the repository yet, although depending on the kind of git reset you run, something else might happen before git reset finishes: the first step of this git reset is just to change one of your own branch names. Since you're considering (or have used) --hard, some more things will change in your repository, but they're less important at the moment.

2. Every Git repository has its own branch names. Moving one of your branch names has no effect on any other repository.

3. What you need to do is to get some other Git repository to change one of its branch names. That's where you run into this problem:

   I cannot push this (I need to pull before and pulling moves me forward).

   The git push command is how you ask—or, using --force, command—some other Git repository to change or create or delete some of its names (branch names, tag names, and other such names). But each Git repository is set up to easily accept new incoming commits, yet at the same time, resist the suggestion to throw away any existing commits.

When you use git reset to move one of your branch names "backwards", so as to revert to (not revert as in add-a-commit-that-backs-out) some previous commit, you're deliberately throwing away some existing commit(s). Since you control your own Git repository, you can definitely do this to your own repository. Since the git reset command is meant to do this kind of throwing-away,¹ it does so without complaint. But git push isn't, and their Git complains.

As soon as you use git pull, their repository has you put back all the commits you snipped out of your own repository. Git is, after all, designed to add commits as easily as possible! That leaves you with the situation you're in.

You now have a choice:

• Force the other Git repository to discard some commits. This requires sufficient permissions. It also means that everyone else who is using that other Git repository need to take action with any clones they have made, because their clones will enthusiastically put back all the commits you are attempting to prune. So this is kind of mean to those other people.

• Or, use git revert or some other command to add some commit(s) to your repository that, in the end, result in putting the files back, but don't remove any old commits. The new commits simply add on to the old ones. The old ones are still there for anyone who would like to ask about them (git log) or use them (git switch --detach hash-id, for instance).

Adding new commit(s) is what Git is designed to do, so the latter is the way to go unless there's some really strong reason to ditch the old commits.

As the question you linked notes, all of this is a lot easier with unpublished commits: a commit that only you have, in your own private repository, is simply not in any other Git repository. If you shave those commits off your own branches, nobody will ever know. They won't be able to object that a git push shaves those commits off their branches, because those commits aren't on their branches. (Again, each branch name is local to each Git repository. One repository can show another one the commit hash ID stored in its branch name, but each repository takes responsibility in keeping its own hash IDs in its own branch names. The commits get shared; the branch names do not.)

Since the commits you're looking at are published you cannot use this short-cut.

¹This makes git reset a very-high-powered tool, like some sort of flame-throwing chainsaw, or industrial steel-cutting laser, or something. This over-powered-ness is part of the reason that Git 2.23 now has git restore: some of the things you can do, that used to require using git reset, can now be done with the rather gentler git restore. Both commands will throw away in-progress work if you ask them, but git restore is more like a hand-saw, or bolt cutters, or something along these lines.