首页 > 解决方案 > Git Rebase 与 BitBucket

问题描述

我遇到了一个让我大吃一惊的问题。我的分支中有与 master 冲突的代码(在我的例子中是开发)。这不是一个大问题,因为它实际上是很容易识别的 7 行代码。

BitBucket 很友好地让我知道,为了解决合并冲突,我需要执行以下步骤。

在分支上<current branch> ,您的分支和“ <current branch>”已经分道扬镳,分别有 4 和 3 个不同的提交。
(使用“git pull”将远程分支合并到你的)

没什么可提交的,工作树干净

好的,没问题,让我们运行 git pull... 我们必须重新开始,就好像我从未修复过合并冲突一样。

我正在阅读其他类似问题的评论,发现有人使用 -f 标志(强制)推送代码。我试过了,当然它有效,但是我的 7 行更改变成了多个文件更改。合并冲突已经消失,但我担心主(开发)分支会因不必要的提交而膨胀。

标签: gitmergerebase

解决方案


TL;DR:你需要git push --force-with-lease origin HEAD.

您遇到此问题是因为您正在使用 rebase。(Bitbucket 在这里不相关;我剪掉了那个标签。)

变基操作的核心是对 Git 的命令,格式如下:

  • 我有一些旧的提交。他们……还可以,但还不够好。
  • 删除旧的提交,创建一些新的和改进的替换提交来代替。

完成后,旧的提交就消失了(ish 1),您现在正在使用新的和改进的替换提交。

当您运行时git push origin HEAD,您的 Git 会将您的名称解析HEAD为您当前的分支名称(无论该名称是什么),并且就像您运行. 这会让你的 Git 在 at 调用他们的 GIt,发送你的新提交,然后礼貌地询问他们是否愿意,如果可以,设置他们的分支名称以标识与你的分支名称标识的最后一次提交相同的提交。git push origin branchorigin

因为您使用了 rebase,所以请设置分支名称 ______(用名称填写)到 _______(用哈希 ID 填写)相当于他们的Git 的指令形式:Throw away the same old commits I throw away, using these same replacement提交。但是此时他们不知道您的新替换提交替换。他们已经完全忘记了他们之前告诉你的任何事情。他们只看到你要求他们放弃一些提交。所以他们说不!如果我这样做,我会丢失一些提交。

为了克服他们不愿放弃提交的问题,您必须向他们发送更有力的命令,而不是礼貌的请求。你必须告诉他们:是的,我知道这可能会丢弃一些提交。还是去做吧! 为此,您必须在命令中使用--forceor--force-with-lease选项。git push

从某种意义上说,该--force-with-lease选项“更安全”:当您使用此选项时,您的命令具有以下形式:我希望您更新_____(用分支名称填写空白)。我相信您的最新提交是 _______ (用哈希 ID 填空)。如果是这样,丢弃一些提交;使用______(用哈希ID填空)。 您的 Git 会填写所有空白并将其发送过来。如果自您的 Git 上次与他们的 Git 对话以来,他们的 Git 没有累积任何新的提交,那么您的替换提交就是正确的替换,如果他们服从这个强有力的命令,那就行了。

--force选项跳过安全检查:将______(用名称填空)更新为_____(用哈希ID填空)! 只要自从您开始工作以来没有其他人添加新的--force-with-lease提交,这个强有力的命令就会与更谨慎的.

当你使用git pull而不是git push强制选项时,你会得到他们最新的提交——这是你之前在替换时丢弃的提交——现在你遇到了同样的问题。无论是使用 fetch-and-rebase pull 还是 fetch-and-merge pull,您都可以通过任何类型的 pull 来获得它。(我个人建议避免 git pull:运行git fetch自己,然后根据您的意图运行一个git mergegit rebase自己。然后当它出错时,您知道哪个命令实际上失败了。当您使用git pull运行两个Git 命令为您服务,但有些事情失败了,您甚至可能不知道哪个 Git 命令失败了。但是有些人发现输入一些额外的字符很困难。正如您根据我的答案的长度所看到的那样,我没有这个特殊问题。)


1 Git 对提交非常贪婪,并且不愿放弃任何提交。出于这个原因,作为备份,以防你改变主意,旧的提交还没有真正消失。默认情况下,您至少有 30 天的时间才能真正消失。不过,在这 30 天的窗口中恢复它们会有点痛苦。


推荐阅读