这是一个创建于 3411 天前的主题，其中的信息可能已经有所发展或是发生改变。
在自己的分支下`push -f`结果造成`master`被强推，原因是`push.default`的设置是`matching`
啊啊啊死
啊啊啊死
第 1 条附言 · 2015-07-30 21:58:15 +08:00
原因1：特喜欢amend，还喜欢时不时push，然后就名正言顺地用强推来amend了
原因2：看见警告提示说没有设置push.default就按照提示里的随便设了一种
原因2：看见警告提示说没有设置push.default就按照提示里的随便设了一种
第 2 条附言 · 2015-07-30 22:50:04 +08:00
花了很多时间找补救方法（无法完全控制git服务器的情况，比如github）：
直接clone remote或者fetch是没用的，那些dangling commit不会被拉过来。所以在本地用的那套补救法就无用了。github虽然不能通过ssh执行shell命令，但有提供2组api，对应了本地补救法的前2步。
gitlab似乎不行，第一步可以在网站上完成，但没办法执行第二步
直接clone remote或者fetch是没用的，那些dangling commit不会被拉过来。所以在本地用的那套补救法就无用了。github虽然不能通过ssh执行shell命令，但有提供2组api，对应了本地补救法的前2步。
gitlab似乎不行，第一步可以在网站上完成，但没办法执行第二步
 |
1
LPeJuN6lLsS9 OP github简单版补救方法，没有博客所以记这：
通过各种手段得到强推之前的一个commit的hash，比如在github可以看组织的dashboard。然后查看那个commit所在时间点的整个repo，再在这个“tree view”的基础上建新分支。如此这个分支就含有丢失的commit了。然后回本地pull新建的，再强推一次到master 应该比这里的方法简单点，毕竟不用API： https://objectpartners.com/2014/02/11/recovering-a-commit-from-githubs-reflog/ |
|
2
LPeJuN6lLsS9 OP 纠正，merge新建的“恢复分支”到master根本不用强推
以后可以尽情地强退啦 |
Select Language