如何在不破坏树的情况下重新设置推入的分支? [英] How to rebase pushed branches without ruining tree?

问题描述

我是唯一一个在资源库中工作的开发人员，因此破坏人们的工作流程没有任何问题.但是，当我在本地重新设置基准，然后尝试将其推送到Bitbucket时，它又回来告诉我我需要提取最新的更改.我这样做了，重新部署完全破坏了我的干净树.

I'm the only developer working in a repository, so there's no issue with ruining peoples' flow. However when I rebase locally and then try and push it to Bitbucket, it comes back telling me I need to pull the latest changes. I do that, and the rebase has completely ruined my clean tree.

是否有一种方法可以在不进行额外的合并分支"提交的情况下将基准服务器推送到服务器?

Is there a way to push a rebase to the server without then having an additional "Merge branch" commit as part of it?

谢谢！

推荐答案

从根本上说，Rebase是复制一些提交，然后丢弃旧的提交以支持新的和改进的提交"操作.

Rebase is fundamentally a "copy some commits, then discard the old commits in favor of the new and supposedly improved commits" operation.

例如，考虑这种情况:

...--A--B--E--F   <-- master
         \
          C--D--G   <-- feature (HEAD)

您已经完成了功能feature，但是无论出于何种原因，您都必须在工作时在master上创建两个提交.所以现在feature应该可以重写了.

You've finished your feature feature, but for whatever reason, you had to go create two commits on master while you were working. So now feature could stand to be re-written.

任何提交都不能更改，因此实际上不可能用新的和改进的版本来替换 C，但是我们可以做一个新的-改进的C'可以使用临时分支或Git的分离式HEAD"模式来替换C:

No commit can ever change, so it's not actually possible to replace C with a new-and-improved variant, but we can make a new-and-improved C' to replace C anyway, using a temporary branch or Git's "detached HEAD" mode:

                C'  <-- HEAD
               /
...--A--B--E--F   <-- master
         \
          C--D--G   <-- feature

提交C'提交F的行为与提交C提交B的行为相同.旧的(现在很糟糕)的C以B作为其父级，而新的改进的C'以F作为其父级.因此，现在我们需要将D复制到新的和改进的D'中，然后再次对G执行相同操作:

Commit C' does to commit F what commit C does to commit B. The old (and now lousy) C has B as its parent, while the new improved C' has F as its parent. So now we need to copy D to a new-and-improved D', and then do the same again for G:

                C'--D'--G'  <-- HEAD
               /
...--A--B--E--F   <-- master
         \
          C--D--G   <-- feature

我们现在准备好git rebase的最后一招.它将名称feature从提交G中剥离，并使feature指向G':

We're now ready for git rebase's last trick. It peels the name feature off of commit G and make feature point to G' instead:

                C'--D'--G'  <-- feature (HEAD)
               /
...--A--B--E--F   <-- master
         \
          C--D--G   [abandoned]

由于我们甚至无法看到被遗弃的提交，因此在笔记本电脑的本地存储库中，历史似乎一直都是这样:您基于F，依此类推.哈希ID看起来是随机的；没有人，但是您将一无所知.

Since we can't even see the abandoned commits, in the local repository on your laptop, it looks as though history has always been this way: that you wrote commit C' based on F, and so on. The hash IDs look random; no one but you will ever know about all this.

仅...您对Bitbucket进行了git push的提交C-D-G或至少其中的一些提交. 它们具有您的旧式提交，由其分支名称feature指向.您将它们发送给您新的闪亮的git push origin feature，最后，您的Git要求他们移动其 feature名称以指向提交G'而不是G

Only ... you did a git push of commits C-D-G, or at least some of them, to Bitbucket. They have your old-and-lousy commits, pointed-to by their branch name feature. You send them your shiny new ones—git push origin feature—and at the end of this, your Git asks them politely to move their feature name to point to commit G' instead of G.

这当然会导致 them 放弃提交G，而使用新的和改进的G'.那就是你想要他们要做的.但是他们会说:不，如果我这样做，我将失去我宝贵的承诺G！

This would, of course, cause them to abandon commit G in favor of the new and improved G'. That's what you want them to do. But they will say: No, if I do that, I'll lose my precious commit G!

您所要做的就是告诉他们-或让您的Git告诉他们-是的，我知道您可能会丢失一些提交，但还是要这样做！也就是说，这不是礼貌的请求，您让Git向他们发送了强有力的命令.

All you have to do is tell them—or have your Git tell them—yes, I know you could lose some commits, but do it anyway! That is, instead of a polite request, you have your Git send them a forceful command.

执行此操作的方法是将--force或--force-with-lease添加到git push命令中.这就礼貌了，请，如果可以，请将您的feature 设置为命令:设置您的功能！

The way you do this is to add --force or --force-with-lease to your git push command. That turns the polite request, Please, if it's OK, set your feature to a command: Set your feature!

--force和--force-with-lease之间的区别在于，后者首先添加了安全检查.您的Git不仅会说将您的名字feature设置为指向提交G'！，还会说:根据我的信息，我认为您的feature指向提交G.如果是这样，请将其设置为指向G'.如果没有，让我知道我很讨厌.

The difference between --force and --force-with-lease is that the latter adds a safety check first. Instead of just saying Set your name feature to point to commit G'!, your Git will say: I think, based on my information, that your feature points to commit G. If so, set it to point to G' instead. If not, let me know that I goofed.

安全检查通常通常很好，但是如果您是唯一将新提交提交到Bitbucket上的存储库中的人，则也没有必要.

The safety check is obviously usually good, but it's also unnecessary if you're the only one who ever puts new commits into the repository over on Bitbucket.

这篇关于如何在不破坏树的情况下重新设置推入的分支?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！