How to submit the rolled-back old version of the code and the changed files to the main branch on github

Question

Maybe what I said is not very clear, but as I was writing the code, I found that I no longer wanted to do it, so I used git reset --hard <version number> to return to the previous one. Rewrite the version so that when I finish writing and want to submit it to the remote warehouse, it will report an error

To https://github.com/zifenggao/wenda.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://github.com/zifenggao/wenda.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

It says that my version is the previous one and they want me to merge it and then submit it. How should I do it? I tried it several times but I still don’t understand it.

Answer 1

First of all, according to your description, since you used git reset --hard, it can be inferred that you have already add and commit.
Secondly, based on the error report, it can be inferred that you have already push (This inference is based on the fact that only you have the change permissions of the master branch.

Then when you execute git reset --hard, the historical records cannot be directly merged with the remote records. That's why there is this error.

For example, the remote is A -> B -> C -> D, you git reset --hard followed by A -> B. At this time, unless the remote side erases C and D, it cannot be merged.

Therefore, at this time, you should use git push origin master --force to forcibly overwrite the remote records.

Please do not use git pull according to the prompts. Otherwise, your local area will become A -> B -> C -> D. Because git pull is equivalent to git fetch + git merge

---

(The following content is based on the above example, the remote is A -> B -> C -> D, you want to roll back to the state of B)

mentioned git revert upstairs. In fact, both git reset --hard and git revert can achieve "rollback code". But the difference is:

git revert will turn your local into A -> B -> C -> D -> E. Among them, what E does is delete C and D. The advantage of this is that when you git push origin master you won’t have the above error. However, the two commits C and D will still be retained on the history line. If using this command, remember to add and then commit.

git reset --hard will directly delete C and D, resulting in a result like A -> B. The advantage is that it is more direct and thorough. The disadvantage is that you must first force changes through git push origin master --force. Secondly, once you regret it, there is no other way unless you directly restore the HEAD pointer according to the local reflog.

No matter which one you use, please choose according to your needs.

Answer 2

Generally speaking, try to avoid this situation.

If you have permission to the remote master, you can do this:

git push --force

A more reasonable approach is to use git revert

---

Edit dividing lines

Another student @S1ngS1ng’s answer is more detailed, but he raised the point that any one can be used. I still have to reiterate that git revert is the more appropriate approach

When it is a multi-person development scenario, it is very likely that the latest code has been pulled to the remote master by others or merged into other branches. In this case, reset will be invalid, because the other party may still push it up and you want to delete it. commit

So this idea that you can use any one actually has limitations