git branch -m对其他开发人员有副作用吗？

我们已经学会了如何切换哪些分支指向使用的git branch -m.如果我这样做,是否会让其他人从我的存储库中拉出来让生活变得困难？

假设我在分支上做了很多东西topic1,然后做了一个

git branch -m master old_master
git branch -m topic1 master
git push origin master

然后别人master从我的远程存储库中拉出来,他们需要做些什么才能让一切都指向正确的位置？我是否必须告诉所有人重复我的步骤？

这是否类似于在推送它们并让其他开发人员留下悬挂物体后重新定位提交的问题？

我不确定你的回购是什么样的,但这是最糟糕的情况.

假设您的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中的更改将返回到存储库中(oops!).相反,她不得不cherry-pick和rebase她的GHI改变到origin/master.

Git让你这么做很酷,但它有点麻烦.你真的希望莎莉注意到这种情况.这就是为什么你应该警告所有其他贡献者,这样他们就可以适当地处理变更.

注意:以上是最糟糕的情况.如果你的topic1分支机构离开master了C,那么这种变化是快速前进的,没有任何问题.