如何在不破坏树的情况下重新设置推送的分支？

Question

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

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

谢谢！

Answer 1

Rebase从根本上来说是“复制一些提交，然后丢弃旧的提交以支持新的和应该改进的提交”操作。

例如，考虑这种情况：

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

您已经完成了功能feature，但是出于任何原因，您都必须在工作时在master上创建两个提交。因此现在feature可以重写。

没有提交可以ever进行更改，因此实际上不可能用新改进的变体replace C，但是我们可以制作新改进的C'来替换C无论如何，使用临时分支或Git的“分离头”模式：

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

Commit C'确实提交了F，而commit C确实提交了B。旧的（现在很糟糕）的C将B作为其父级，而新的改进的C'将F作为其父级。因此，现在我们需要将D复制到新的和经过改进的D'，然后再次对G执行相同的操作：

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

我们现在已经准备好git rebase的最后把戏。它将名称feature从提交G中剥离，并使feature指向G'：

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

由于我们甚至无法参见放弃的提交，因此在笔记本电脑的本地存储库中，历史似乎一直都是这样：您基于C'编写了提交F，并且以此类推。哈希ID看起来是随机的；没有人，但是您永远都不会知道这一切。

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

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

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

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

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

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