8

我们已经学会了如何使用git branch -m. 如果我这样做，是否会让其他人从我的存储库中提取生活困难？

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

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

然后其他人master从我的远程存储库中提取，他们必须做什么才能使所有内容都指向正确的位置？我必须告诉所有人重复我的步骤吗？

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

4

2 回答 2

7

我不确定你的回购是什么样子，但这是最坏的情况。

假设您的origin存储库看起来像这样

起源：
o---o---A---B---C 大师

你的本地存储库看起来像这样，

吉姆普尔斯：
o---o---A---B---C 主控，起源/主控
         \
          D---E---F 话题1

然后，在您的分支重命名后，您的本地存储库如下所示：

吉姆普尔斯：
o---o---A---B---C old_master, origin/master
         \
          D---E---F主

现在，当你推动master那origin将是一个非快进更新。推送后，origin存储库将如下所示：

起源：
o---o---A...B...C（B & C 是孤立的提交）
         \
          D---E---F主

这对于可能在C. 例如，如果 Sally 与您合作，她的存储库可能如下所示：

莎莉：
o---o---A---B---C 原点/主控
                 \
                  G---H---我掌握

现在，如果您执行非快进推送，而 Sally 执行fetch她的存储库，则会如下所示：

莎莉：
          D---E---F 原点/主控
         /
o---o---A---B---C  
                 \
                  G---H---我掌握

现在 Sally 必须弄清楚如何将她的工作（G、H、I）恢复到存储库中。如果她只是进行合并，origin/master那么 B 和 C 中的更改将返回到存储库中（哎呀！）。相反，她将不得不cherry-pick或rebase她的 GHI 更改为origin/master.

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

注意：以上是最坏的情况。如果您的topic1分支从masterC 出发，那么这种变化是快进的，没有问题。

于 2009-04-01T11:46:06.953 回答
0

基本上你的操作是一样的：

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

他们会产生这种效果：其他人都会得到这个topic1分支（不过它是以他们的名字命名的）和它的祖先，master直到第一次分歧的地方。然后，旧分支就在他们的存储库中，将来某个时候将被垃圾收集，因为没有任何东西指向它了。mastertopic1master

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

于 2009-04-01T10:48:20.073 回答