我们使用git branch -m 使用already learned how to switch which branch points to what。如果我这样做，是否会让其他人从我的存储库中提取数据变得困难？
假设我在分支topic1 上做了一堆东西，然后做一个
git branch -m master old_master
git branch -m topic1 master
git push origin master
然后其他人从我的远程存储库中提取master，他们需要做什么才能使所有内容都指向正确的位置？我需要告诉所有人重复我的步骤吗？
这是否类似于在推送提交后重新定位提交并给其他开发人员留下悬空对象的问题？
【问题讨论】：
我不确定你的回购是什么样子，但这是最坏的情况。
假设您的 origin 存储库如下所示
您的本地存储库看起来像这样，
吉姆普尔斯： o---o---A---B---C 主控，起源/主控 \ D---E---F 话题1然后，在您的分支重命名后，您的本地存储库将如下所示：
吉姆普尔斯： o---o---A---B---C old_master, origin/master \ D---E---F主现在，当您将 master 推送到 origin 时，这将是一个非快进更新。推送后，origin 存储库将如下所示：
这对于可能在 C 之上进行提交的朋友来说可能是残酷的。例如，如果 Sally 与您合作，她的存储库可能如下所示：
现在，如果您执行非快进推送，而 Sally 执行 fetch，她的存储库将如下所示：
现在，Sally 必须弄清楚如何将她的工作（G、H、I）恢复到存储库中。如果她只是与origin/master 合并，那么 B 和 C 中的更改将返回到存储库中（哎呀！）。相反，她必须将 cherry-pick 或 rebase 她的 G-H-I 更改为 origin/master。
Git 允许您这样做很酷，但它有点自找麻烦。你真的希望莎莉注意到这种情况。这就是为什么您应该在这样做时警告所有其他贡献者，以便他们能够适当地处理更改。
注意：以上是最坏的情况。如果您的 topic1 分支在 C 处从 master 出发，那么该更改是快进并且没有问题。
【讨论】：
基本上你的操作是一样的：
# git checkout master
# git reset --hard topic1
# git push origin master
他们将产生这种效果：其他所有人都将获得 topic1 分支（不过，对于他们来说，它被命名为 master）及其祖先直到 master 和 topic1 第一次分歧的地步。然后，旧的 master 分支就在他们的存储库中，并且将在将来的某个时候被垃圾收集，因为没有任何东西指向它了。
如果topic1 是源自master 的当前HEAD 的一个分支，那么这里就可以了。否则，您将陷入“重写历史”的情况，这可能会使您的例如一团糟。你的标签。您需要仔细考虑您真正想要实现的目标。也许一个简单的git merge 会更好地为您服务？
【讨论】：