代码之家 › 专栏 › 技术社区 › Jim Puls

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

branch merge git

Jim Puls · 技术社区 · 15 年前

我们已经 already learned how to switch which branch points to what 使用 git branch -m . 如果我这样做,是否会使其他人从我的存储库中提取信息变得困难?

比如说我在树枝上做了很多事情 topic1 然后做一个

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

然后有人拉 master 从“我的远程存储库”中,他们需要做什么才能使一切指向正确的位置?我要告诉大家重复我的步骤吗?

这是否类似于在推送提交并让其他开发人员拥有悬空对象之后重新平衡提交的问题?

2 回复 | 直到 15 年前

Pat Notz 15 年前

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

假设你 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:
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

现在,如果你做了非快速向前推,莎莉做了一个 fetch 她的存储库如下所示:

Sally:
          D---E---F  origin/master
         /
o---o---A---B---C  
                 \
                  G---H---I  master

现在萨利必须弄清楚如何把她的工作(G,H,I)放回存储库。如果她只是和 origin/master 然后B和C中的更改将返回到存储库中(oops!)相反,她必须 cherry-pick 或 rebase 她的G-H-I变成了 起源/大师 .

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

注: 以上是最坏的情况。如果你 topic1 分支机构离开 主人 在C点,然后换是快速前进,没有问题。

Bombe 15 年前

基本上,您的操作与以下操作相同:

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

他们会有这样的效果:其他人都会得到 topic1 分支(IT_s命名 master 但对于他们来说)及其祖先 主人 和 TopIC1 第一次分歧。老年人 主人 然后,分支就躺在它们的存储库中,在将来的某个时候将被垃圾收集,因为没有任何东西指向它。

如果 TopIC1 是源于当前 HEAD 属于 主人 你在这里会很好的。否则,您将进入_重写历史_的情况,这可能会弄乱您的标签,例如。你需要仔细考虑你真正想要达到的目标。也许简单 git merge 能更好地为您服务吗?