我不确定你的repo长什么样,但这是最坏的情况。假设你的
origin
仓库看起来像这样:
origin:
o---o---A---B---C master
而你的本地仓库看起来像这样:
JimPuls:
o---o---A---B---C master, origin/master
\
D---E---F topic1
然后,在你重命名分支之后,你的本地仓库看起来像这样:
JimPuls:
o---o---A---B---C old_master, origin/master
\
D---E---F master
现在,当你将
master
推送到
origin
时,这将是一个非快进更新。推送后,
origin
仓库将会变成这样:
origin:
o---o---A...B...C (B & C are orphaned commits)
\
D---E---F master
这可能会对那些在
C
之上提交了提交的朋友造成困扰。例如,如果Sally和你一起工作,她的仓库可能看起来像这样:
Sally:
o---o---A---B---C origin/master
\
G---H---I master
现在,如果你进行非快进推送,然后Sally执行
fetch
,她的仓库将会变成这样:
Sally:
D---E---F origin/master
/
o---o---A---B---C
\
G---H---I master
现在Sally必须想办法将她的工作(G、H、I)重新放回仓库。如果她只是与
origin/master
合并,那么B和C中的更改将重新出现在仓库中(糟糕!)。相反,她将不得不将她的G-H-I更改
cherry-pick
或
rebase
到
origin/master
上。
Git让你这样做很酷,但这有点危险。你真的希望Sally注意到这种情况。这就是为什么在执行此操作时应该警告所有其他贡献者,以便他们可以适当地处理更改。
注意:以上是最坏的情况。如果你的
topic1
分支从C开始,则该更改是快进的,没有问题。