我遇到了一个让我困惑的问题。我的分支中有与 master 冲突的代码（在我的例子中是开发）。这不是一个大问题，因为它实际上只有 7 行代码，很容易识别。
BitBucket 很友善地告诉我，为了解决合并冲突，我需要执行以下步骤。
<branch in question><master>（在我的例子中是开发）
<conflicted_files>”将它们标记为已解决，然后运行“git rebase --continue”。”<current branch>在分支上
<current branch>您的分支和“<current branch>”已经分歧，并且分别有 4 个和 3 个不同的提交。
（使用“git pull”将远程分支合并到您的分支中）没有什么可提交的，工作树干净
好吧，没问题，让我们运行 git pull...我们必须重新开始，就好像我从未修复过合并冲突一样。
我正在阅读其他有类似问题的评论，发现有人使用 -f 标志（强制）推送代码。我尝试过，当然它有效，但是我的 7 行更改变成了多个文件更改。合并冲突消失了，但我担心主（开发）分支会因不必要的提交而膨胀。
TL;DR：你需要git push --force-with-lease origin HEAD。
您遇到此问题是因为您正在使用变基。（Bitbucket 与此处无关；我剪掉了该标签。）
\n变基操作的核心是对 Git 的命令，其形式为：
\n完成后，旧的提交消失了（ish 1），您现在正在使用新的和改进的替换提交。
\n当您运行 时git push origin HEAD，您的 Git 会将您的名称解析HEAD为当前分支名称\xe2\x80\x94，无论该名称是什么\xe2\x80\x94，并且就像您运行了一样。这会让你的 Git 调用他们的 GIt，通过 at发送你的新提交，然后询问他们\xe2\x80\x94礼貌地\xe2\x80\x94如果他们愿意的话，如果可以的话，设置他们的分支名称以标识相同的您的分支名称标识的最后一次提交。git push origin branchorigin
因为你使用了 rebase，所以请将分支名称 ______（填写名称）设置为 _______（填写哈希 ID）相当于对他们的Git 形式的指令：扔掉我扔掉的相同旧提交，使用这些相同的替换承诺。但此时他们不知道您的新替换提交是替换。他们已经完全忘记了之前告诉过你的一切。他们只看到您要求他们放弃一些提交。所以他们说不！如果我这样做，我会失去一些承诺。
\n为了克服他们不愿意放弃提交的情况，您必须向他们发送更有力的命令，而不是礼貌的请求。你必须告诉他们：是的，我知道这可能会丢弃一些提交。无论如何都要做！ 为此，您必须在命令中使用--force或选项。--force-with-leasegit push
--force-with-lease从某种意义上说，该选项“更安全”：当您使用此选项时，您的命令具有以下形式：我希望您更新_____（用分支名称填写空白）。我相信您最新的提交是 _______（用哈希 ID 填写空白）。如果是这样，请丢弃一些提交；使用 ______（用哈希 ID 填空）。 你的 Git 填写了所有空白并将其发送过来。如果自上次您的 Git 与他们的 Git 通信以来，他们的 Git尚未积累任何新提交，那么您的替换提交就是正确的替换，并且如果他们遵守这个强制命令，那就可以了。
该--force选项跳过安全检查：将 ______（用名称填写空白）更新为 _____（用哈希 ID 填写空白）！ 只要自您开始工作以来没有其他人添加新的提交，这个强有力的命令就能达到与更谨慎的命令相同的结果--force-with-lease。
当您使用git pull而不是git push使用强制选项时，您会得到他们最新的提交\xe2\x80\x94，这是您之前在进行替换时抛出的提交\xe2\x80\x94，现在您遇到了同样的问题。您可以通过任何类型的拉取来获得此结果，无论是使用 fetch-and-rebase pull 还是 fetch-and-merge pull。（我个人建议避免 git pull：自己运行，然后根据您的意图git fetch运行其中一个git merge或自己。然后当出现问题时，您知道哪个命令实际上失败了。当您用来为您运行两个Git 命令并且出现故障时，你甚至可能不知道哪个 Git 命令失败了。但是有些人发现输入一些额外的字符很困难。正如你根据我的答案的长度所看到的，我没有这个特殊的问题。）git rebasegit pull
1 Git 对提交非常贪婪，并且不愿意放弃任何提交。出于这个原因，并且作为备份，以防万一您改变主意，旧的提交还没有真正消失。默认情况下，您至少有 30 天的时间，他们才会真正消失。不过，在 30 天的时间内恢复它们会有点痛苦。
\n