这样做push --force
总是有风险的,这里有一个例子说明它如何产生一些问题,比如远程丢失修订。
假设,有人Bob已将远程master
分支从更新B
为C
。还有另一个人Mike尚未获取此更新,HEAD
而他master
的仍然是B
. 然后Mike
执行push --force
并突然回滚远程master
再次B
:
mike@laptop $> git push --force origin
Counting objects: 19, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (12/12), 2.27 KiB, done.
Total 12 (delta 8), reused 0 (delta 0)
remote: => Syncing... [OK]
To git@gitserver.com:path/to/project.git
C..B master -> master (forced update)
换句话说,在迈克这样做之前,远程大师就像A---B---C
,他将其更改为A---B
。
如您所见,C
这里的修订仅是远程的-它存在于 git-server 和Bob的笔记本电脑上,因为他将其推送到了 remote master
。这意味着Mike的笔记本电脑C
上没有这样的本地 ref。
问题1 :麦克如何设置遥控master
器C
?
迈克试图再次解决这个问题,push --force
就像类似问题提供的答案一样,但它不起作用,因为没有吸本地参考:
mike@laptop $> git push --force origin C:master
error: src refspec C does not match any.
error: failed to push some refs to 'git@gitserver.com:path/to/project.git'
问题 2 : Mike如何C
从 git 服务器获取修订版?如果他不能那样做 - 为什么 git 设计成那样?在极少数情况下是否与安全有关?它究竟能防止什么问题?
通常fetch
只检索分支和标签,但C
不属于任何分支(这意味着没有任何远程分支C
是父提交或HEAD
属于)。
PS:我们假设Mike没有 ssh 访问 git server 的权限,也就是说没有办法从 server 端调用 git。
PPS:迈克不想让鲍勃知道那次事故,所以回答“让鲍勃再次推送这个提交”不是这个问题的意义所在。