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

Question

我们已经学会了如何使用git branch -m切换分支。如果我这样做，会不会给从我的存储库拉取的其他人带来麻烦？

比如我在一个名为topic1的分支上做了很多事情，然后执行

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

如果其他人从我的远程仓库拉取master分支，他们需要做什么才能使一切指向正确的位置？我是否需要告诉每个人重复我的步骤？

这是否类似于推送提交后重新定位提交并留下悬空对象的问题？

- Jim Puls

Answer 1

我不确定你的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开始，则该更改是快进的，没有问题。

- Pat Notz

Answer 2

基本上你的操作与以下相同：

# git checkout master
# git reset --hard topic1
# git push origin master

它们将确切地产生这种效果：其他人将获得topic1分支（对于他们来说，它被命名为master），以及它的祖先，直到master和topic1首次分叉的点。旧的master分支就留在他们的存储库中，并且将在未来的某个时候进行垃圾回收，因为没有任何东西指向它。

如果topic1是从当前master的HEAD衍生出来的分支，那么你在这里就没问题了。否则，你将陷入“重写历史”的情况，这可能会搞乱你的标签等等。你需要仔细考虑你真正想要实现什么。也许一个简单的git merge会更好地为你服务？

- Bombe