可能说的不是很明白，就是我代码写着写着，发现我已经不想这么弄了，用git reset --hard <版本号>退回到之前的某个版本重新写，这样当我当我写完之后，想在提交到远程仓库，它就会报错
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.说我版本是之前的版本，要我合并后再提交，那我应该怎么弄，能了几遍都没搞懂。
黄舟2017-06-16 09:21:00
首先，根据你的描述，既然你用到了 git reset --hard，那就可以推断出你已经 add 和 commit 过了。
其次，根据报错，可以推断出你已经 push 过了（这个推断基于只有你一个人拥有 master branch 的更改权限。
那么当你执行 git reset --hard 之后，历史纪录是不能跟远程的记录直接合并的。因此才会有这个报错。
举个例子，远程是 A -> B -> C -> D，你 git reset --hard 之后是 A -> B。这时候除非远程那边抹掉 C 和 D，你
A -> B。这时候除非远程那边抹掉 C 和 D，否则是不能合并的。
git push origin master --force因此，这时候，你应该使用 来强行覆盖远程记录。
git pull。否则，你的本地又会变成 A -> B -> C -> D。因为 git pull 相当于 git fetch + git merge请不要根据提示使用
A -> B -> C -> D（以下内容基于上面的例子，远程是
git revert。其实，git reset --hard 和 git revert楼上提到了 git revert。其实，
git revert 都可以实现“回滚代码”。但区别在于：
git revert 会把你的本地变成 A -> B -> C -> D -> E。其中，E 干的事儿是删除 C 和 D。这样做的好处在于，你 git push origin master 就不会有上面的报错了。但，历史线上还是会保留 C 和 D 这两个 commit。如果使用这个命令，记得要 add 然后 commit
git reset --hard 会直接删掉 C 和 D，形成 A -> B 这样的结果。好处在于更直接更彻底。缺点在于，首先要通过 git push origin master --force 去强行更改。其次，一旦你后悔了，除非根据本地的 reflog
C 和 D，形成 A -> B 这样的结果。好处在于更直接更彻底。缺点在于，首先要通过 去强行更改。其次，一旦你后悔了，除非根据本地的 reflog 直接恢复 HEAD 指针，此外没有其他办法。
漂亮男人2017-06-16 09:21:00
一般来说, 尽量避免这种情况.
如果你对远程的master有权限, 可以这么做:
git push --force更合理的做法是使用git revert
编辑分割线
另一位同学 @S1ngS1ng 答案更加详细，但是抛出了一个观点是用哪个都可以，这个我还是要重申下 git revert 才是更合适的姿势
当是一个多人开发的场景，很有可能远程的master上已经被其他人pull到了最新代码或者合并到了其它分支，这种情况下reset将无效，因为对方仍然有可能push上来你这里希望删除的commit
所以这个用哪个都可以的观点其实是有限定条件的