有时后我们push某个功能后的所有push都是不被接受的 如为了测试git钩子而做的提交 或者push的提交有问题需要恢复以后重新提交
如以下
把提交到了develop的内容提交到了release_1.2分支 而且只需一次的提交提交了三次 而且不要把develop合并到release1.2上 可以通过u以下方法来解决
1.回滚到5b769d68的版本上 干掉ElasticSearch设置和merge develop to release_1.2的版本
reset --hard 5b769d68
如果想要保存5b769d68到最新版本的代码把hard改为soft 并且提交
2.使用本地代码覆盖掉远程代码
git push -f origin release_1.2
当执行以上代码后git提交记录变成下面的状态
通过上图可以看到develop合并到release_1.2和ElasticSearch服务器地址修改的commit都被干掉了
注意当回滚到某个版本时在那个版本之后的所以提交都会被干掉 所以在多人使用一个仓库时该方式能不用就不用 一定要用是需要跟使用这仓库的其他人确认是否可以通过以上方式回滚到某个版本 只有经过他们的一致同意后才能回滚
否则会造成不必要的损失 如别人提交的代码丢失 后果吗嘿嘿你自己想
假如真的出现以上i情况 在某些情况下还是有办法的(虽然有办法但是我们还是得做到不要出现以上情况)
通过以上方法虽然远程分支上的代码被覆盖了 但是本地还是可以通过reset恢复到用reflog查看到的任意分支上的
如果要恢复的版本可以通过reflog查看到
以上是通过git reflog查询到的结果
根据以上结果可以通过reset恢复到任意版本解决该问题
如果reflog上没有要恢复的分支 只有找到丢失代码的人看他或她的本地仓库上是否可以得到要恢复的代码和版本如果有则还能恢复
可以有些补救方法，首先要找到那个有原来upstream上最新提交的人，让他执行下面这组命令：
方法1：
如果只有两个人（包括你自己）：
git fetch origin develop
git checkout develop
git rebase --onto origin/develop SHA1_CULPRIT develop
git push origin develop
方法2：
如果多于两个人（包括你自己）：
git fetch origin develop
git checkout develop
git cherry-pick SHA1_CULPRIT^..origin/develop
（这时候如果有冲突则解决冲突后执行git add .; git cherry-pick --continue）
git push -f origin master
对于方法2，确保在执行git push -f的时候其他人没有在做push。
注：SHA1_CULPRIT就是上次你跟upstream同步之后提交的第一个commit的sha1 hash。
如果没有嘿嘿只求多副吧~! 但还的试试
如果远端仓库没被gc
$ git clone xxx
$ cd xxx
$ git fsck --lost-found
dangling commit 4d4888a3273a5b56d69df69cbf9698fed7c19a36
$ git show 4d4888a3273a5b56d69df69cbf9698fed7c19a36
commit 4d4888a3273a5b56d69df69cbf9698fed7c19a36
Author: clowwindy <[email protected]>;
Date: Mon Jun 9 12:48:28 2014 +0800
Update README.md
...
确认是你要找的 commit 之后 checkout 这个 commit。然后
$ git branch -D develop
$ git branch -b develop
$ git push -f origin develop
最后一个提醒，99%的场景下，你不需要push --force(push -f)。如果你没有100%确认自己在做什么，没有100%把握知道怎么解决问题，最好别尝试force push。