比防说
我在11点00分从服务器拉取了一次代码，然后与我本地的合并完并且提交了，在11点01分时准备push的时候，提示在我push之前已经有其他人抢险push了，我需要再pull一下才能提交，这时我是否需要将我本地的这一次commit回滚掉？
如果需要回滚我本地的commit该怎么回滚呢？
我现在的做法就是 git reset --hard commitid,这样貌似就把我提交的文件移出暂存区了？我这么做是否正确呢？是否还有其他做法呢？
git pull下来后，
如果有冲突，解决完冲突再commit，然后push就好了；
如果没有冲突，直接就可以push
是不是应该再pull一次，
如果有冲突，就解决冲突之后再commit, push
如果没有冲突，直接commit，push
你从服务器 pull 之后实际上是将之前的抢险 push 合并到了你自己的本地版本之中，结果有两种：
自动合并成功 (fast-forward)
自动合并失败，需要手动 merge
两种情况下，你都应该重新跑一下 test ，确保合并后的代码没有影响你原来的功能和设想。然后再 push.
git fetch origin && git rebase origin/master && git push
答案是不需要.
以下为模拟楼主当前所处的情况:
左侧为本地仓库的状态, 右边为远程仓库.
远程仓库由其他人提交了C2的改动,但楼主的改动是从C1开始的,并提交了两个commit(C3/C4).
在这种情况下,是不能直接 PUSH 的, 而这时候有以下两个操作可以做.
一种是: git pull --rebase
另一种是: git pull (默认行为为: merge)
先说在这种情况下,执行第一种命令时的结果:
可以看到 git 将远程的 C2 获取之后,将本地的 C3/C4 的改动重新叠加了上去,
产生了 C3'/C4' 这两个改动(即它的 hash 值会发生变化, 但内容还是之前改的内容).
在这个时候,执行git push之后的结果:
然后再说第二种情况(git pull):
git 会在获取了 C2 的这个改动之后,将 C2 和 你当前的位置 一起, 进行合并,
然后产生一个新的 commit(C5)
然后再执行 git push 后的结果为:
是不是觉得这种操作在push产生的历史记录不好看 ;)
所以一般情况下, 在遇到楼主的这种情况时, 都使用的是 git pull --rebase, 即将本地的改动 rebase 至远程的改动之后, 这样不会产生合并(C5), 且历史看起来是一条直线.
另外, 在以上两种操作的过程中, 都会遇到不能自动合并,需要手工修改代码,解决冲突.
这种情况取决于你的改动是否与远程别人提交的代码有冲突.