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

Question

我们已经已经学会了如何使用git切换哪个分支指向什么分支-m。 如果我这样做，是否会让其他从我的存储库中提取数据的人的生活变得困难？

假设我在分支 topic1 上做了很多事情，然后做了 a

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

，然后其他人从我的远程存储库中提取了 master，他们需要做什么才能完成所有工作指向正确的地方吗？ 我需要告诉每个人重复我的步骤吗？

这是否类似于在推送提交后重新确定提交并让其他开发人员留下悬空对象的问题？

Answer 1

我不太确定你的仓库是什么样子，但这是最坏的情况。

假设您的 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 推送到 < code>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 中的更改将返回到存储库中（哎呀！）。 相反，她必须cherry-pick或rebase她的GHI更改到origin/master。

Git 允许你这样做很酷，但这有点自找麻烦。 你真的希望莎莉注意到这种情况。 这就是为什么您在执行此操作时应该警告所有其他贡献者，以便他们能够适当地处理更改。

注意：以上是最坏的情况。 如果您的 topic1 分支在 C 处从 master 出发，那么该更改是快进，不会有任何问题。

Answer 2

基本上，您的操作与以下内容相同：

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

并且它们将具有完全相同的效果：其他人都将获得 topic1 分支（不过，它被命名为 master ）及其祖先直到 master 和 topic1 第一次出现分歧。 旧的 master 分支就躺在他们的存储库中，并将在将来的某个时候被垃圾收集，因为没有任何东西指向它了。

如果 topic1 是源自 master 当前 HEAD 的分支，那么您在这里就可以了。 否则，您将陷入“重写历史”的情况，这可能会弄乱您的标签。 您需要仔细考虑您真正想要实现的目标。 也许一个简单的 git merge 会更好地为您服务？