更新被拒绝，因为您当前分支的尖端位于其远程分支的后面

Posted 2023-02-19

【中文标题】更新被拒绝，因为您当前分支的尖端位于其远程分支的后面

【英文标题】：Updates were rejected because the tip of your current branch is behind its remote counterpart

【发布时间】：2017-01-16 21:50:08

【问题描述】：

我们的工作流程就是这样。我们有一个名为dev 的分支，我可以通过origin/dev 联系它。当我们进行更改时，我们会创建一个 dev 分支：

git checkout -b FixForBug origin/dev

现在我有一个名为FixForBug 的分支正在跟踪（我认为这是正确的词）origin/dev。因此，如果我执行git pull，它将带来origin/dev 的新变化，这很棒。现在，当我完成修复后，我会推送到一个名为相同事物的远程分支。

首先，我从origin/dev 中提取所有更改并进行变基：

git pull --rebase

然后我将更改推送到同名的远程分支：

git push origin FixForBug

现在，远程服务器上有一个分支，我可以创建一个拉取请求，以便批准该更改并将其合并回 dev 分支。我自己从来没有向origin/dev 推送任何内容。我猜这是很常见的工作流程。

我第一次执行git push 时，它运行良好并创建了远程分支。但是，如果我按下 秒 时间（假设在代码审查期间，有人指出了问题），我会收到以下错误：

错误：未能将一些引用推送到 'https://github.mydomain.info/Product/product.git' 提示：。在再次推送之前集成远程更改（例如提示：'git pull ...'）。 有关详细信息，请参阅“git push --help”中的“关于快进的说明”。

但是，如果我执行git status，它表示我领先origin/dev 1 个提交（这是有道理的），如果我按照提示运行git pull，它表示一切都是最新的。我认为这是因为我正在推送到与上游分支不同的分支。我可以通过运行来解决这个问题：

git push -f origin FixForBug

在这种情况下，它会将更改推送到远程分支，并表示 （强制更新） 并且所有 似乎 在远程分支上都很好。

我的问题：

为什么在这种情况下需要-f？通常，当您强制某事时，是因为您做错了事，或者至少违反了标准做法。我是否可以这样做，或者它会在远程分支中弄乱某些东西，或者给最终必须将我的东西合并到 dev 中的人造成麻烦？

【问题讨论】：

您收到的消息似乎是远程分支 FixForBug 领先于本地分支 FixForBug。在推送之前，您应该从该远程分支下拉更改并将它们合并到您的本地分支中。

@mhatch - 所以在我推送之前基本上运行git pull origin FixForBug？好的，这是有道理的。随意添加作为答案！

如果您收到此错误，请执行此操作。 ***.com/a/21088381/12201407

Stack Overflow's most copied question with plain text...

@PeterMortensen 哈哈，显然我应该赢得某种奖品！

【参考方案1】：

-f 是实际上是必需的，因为变基。每当您进行变基时，您都需要进行强制推送，因为远程分支无法快速转发到您的提交。您总是希望确保在推送之前先进行拉取，但如果您不想为此强制推送到 master 或 dev，您可以创建一个新分支来推送到然后合并或者做PR。

【讨论】：

您能否澄清一下“您总是希望确保在推动之前先进行拉动”？很清楚为什么在本地分支变基后需要“push -f”。在这种情况下，不会通过 pull w.r.t 来撤消本地的 rebase。推送前的遥控器？

我也在考虑同样的问题，如果我拉出我重新设置基准的文件，那么我将毫无意义地进行重新设置。仍然感谢您的大力推动，但在解决这个问题时遇到了问题。

谢谢。我喜欢你解释了为什么我们必须 -f（强制）。现在说得通了。

这为我节省了很多时间。这在任何解释 git rebase 的博客/教程中都没有提到。非常感谢！

这为我节省了很多时间。谢谢

【参考方案2】：

*"The tip of your current branch is behind its remote counterpart"* 表示远程分支上发生了您本地没有的更改。 Git 会告诉你从REMOTE 导入新的更改并将其与你的代码合并，然后将push 合并到远程。

您可以使用此命令强制更改具有本地存储库的服务器（）。远程仓库代码将替换为您的本地仓库代码。

git push -f origin master

使用-f 标记，您将使用本地回购代码覆盖远程分支代码。

【讨论】：

如果您的分支受到保护，最好启用强制推送

经过几分钟的挫折后，这实际上对我有用

我试过 git push -f 但它说一切都是最新的。还有什么想法吗？

我使用了 'git push -f origin main' 并且成功了

是的。你说对了。 @Yashank

【参考方案3】：

为了确保您的本地分支 FixForBug 不领先于远程分支 FixForBug 在推送之前拉取并合并更改。

git pull origin FixForBug
git push origin FixForBug

【讨论】：

OP 表示他们已经进行了 git pull 并尝试推送。您的回答不适用于 OP 的问题。

最好避免强制推送。感谢分享！

这对我有用！谢谢

【参考方案4】：

设置当前分支名称，如master：

git pull --rebase origin master git push origin master

或分支名称​​develop

git pull --rebase origin develop git push origin develop

【参考方案5】：

如果你想避免使用-f，那么你可以直接使用

git pull

而不是

git pull --rebase

非变基将从origin/dev 获取更改并将它们合并到您的FixForBug 分支中。然后，你就可以运行了

git push origin FixForBug

不使用-f。

【讨论】：

Rebase 是我们工作流程的一部分。如果我不这样做，我会被骂。

@MikeChristensen：好的，那么当然要遵循记录的程序。根据您的描述，您将需要使用-f，因为您将上游存储库上的提交替换 提交具有不同（重新建立）历史的不同提交。如果您要使用Gerrit 之类的产品，那么它支持这种变基代码审查工作流程，而无需在推送时使用-f。我们以这种方式在工作中使用 Gerrit，效果非常好。

【参考方案6】：

我们可以通过以下 cmd 使用本地存储库强制更改 GitHub：

git push -f origin main

【讨论】：

我在本地设置中工作，我只需要强制将我的更改推送到主分支 repo，它对我来说很好

【参考方案7】：

当我遇到消息“更新被拒绝，因为您当前分支的尖端落后”时，我在 Azure DevOps 中使用的命令是/是这个命令：

git pull origin master

（或者可以从一个新文件夹开始并进行克隆）...

此答案并未解决所提出的问题，特别是 Keif has answered this，但它确实回答了问题的标题/标题文本，这将是 Azure DevOps 用户的常见问题。

我注意到 Keif 的回答中的评论：“你总是希望确保在推动之前先拉动”！

除了Git命令行工具，我还用过Git GUI工具。

（我不确定如何在 Git GUI 中执行相当于命令行命令“git pull origin master”的操作，所以我回到命令行执行此操作）。

这张图显示了您可能想要执行的各种操作的各种 Git 命令：

【参考方案8】：

一定是因为提交在你当前的推送之前。

git pull origin "name of branch you want to push"

git rebase

如果git rebase 成功，那很好。否则，您已经在本地解决了所有合并冲突，并继续进行直到 rebase with remote 成功。

git rebase --continue

【参考方案9】：

这就是我解决问题的方法：

让我们假设上游分支是您创建的分支，origin 是您的存储库，并且您希望将 MR/PR 发送到上游分支。

比方说，你已经有大约四次提交，你得到了Updates were rejected because the tip of your current branch is behind.

这就是我所做的

首先，压缩所有四个提交：

git rebase -i HEAD~4

您将获得一个带有pick 的提交列表（在编辑器中打开）。

示例

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

到

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

之后，您可以保存合并的提交

下一步

你需要隐藏你的提交。

方法如下：

git reset --soft HEAD~1
git stash

现在用你的上游分支变基：

git fetch upstream beta && git rebase upstream/beta

现在弹出你隐藏的提交：

git stash pop

提交这些更改并推送它们：

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f

【参考方案10】：

这只是发生在我身上。

我昨天向我们的主人提出了拉取请求。 今天同事审，发现和我们的master分支不同步，为了帮我，把master合并到我的分支。 我不知道他这样做了。 然后我在本地合并master，尝试推送，但是失败了。为什么？因为我的

同事与 master 合并创建了一个我在本地没有的额外提交

！

解决方案：拉下我自己的分支，以便我获得额外的提交。然后push回到我的远程分支。

在我的分支上我确实做到了：

git pull
git push

【参考方案11】：

接下来我帮忙：

git stash
git pull origin master
git apply
git commit -m "some comment"
git push

【讨论】：

你说的“我接下来帮忙”是什么意思（似乎难以理解）？你能详细说明一下吗？

【参考方案12】：

如果你使用 TortoiseGit 推送对话

引用来源：https://tortoisegit.org/docs/tortoisegit/tgit-dug-push.html#id692368

已知更改 - 这允许远程存储库 接受更安全的非快进推送。这可能会导致远程 存储库丢失提交；小心使用它。这可以防止 丢失遥控器上其他人的未知更改。它检查是否 服务器分支指向与远程跟踪相同的提交 分支（已知更改）。如果是，将执行强制推送。 否则会被拒绝。由于 git 没有远程跟踪 标记，不能使用此选项覆盖标记。这通过 git push 命令的 --force-with-lease 选项。

未知更改 - 这允许远程存储库 接受不安全的非快进推送。这可能会导致远程 存储库丢失提交；小心使用它。这不检查任何 服务器提交，因此可能会丢失未知的更改 偏僻的。将此选项与包含标签一起使用以覆盖标签。这 通过 git push 命令的传统 --force 选项。

【参考方案13】：

我在尝试通过 Visual Studio Code 进行变基后推送时遇到了这个问题。我的问题是通过从 Git 输出窗口复制命令并从 Visual Studio Code 的终端窗口执行它来解决的。

在我的例子中，命令类似于：

git push origin NameOfMyBranch:NameOfMyBranch

【参考方案14】：

您必须在您的提交中添加了尚未推送的新文件。检查文件，再次推送该文件，然后尝试拉/推。

它会起作用的。这对我有用...

【参考方案15】：

如果你尝试了前面所有的答案，问题仍然没有解决，那么请确保推送的分支名称是唯一的，并且在远程中不存在。

错误消息可能具有误导性。

【讨论】：

我的帖子没有相关答案。如果有的话，我会同意你的。

【参考方案16】：

推送被拒绝，因为您当前分支的尖端落后。

遇到这种情况，我就跑了：

git push -f origin main

它已经完成了。

【讨论】：

git push -f 将覆盖上游更改，并且在技术上是正确的。大多数时候，您希望将更改添加到现有代码中，因此您需要做的是 git fetch 获取这些更改，然后 git rebase origin/branchname 在上游重播您的更改。可能需要解决合并冲突，但这样您就不会覆盖其他人的工作。

【参考方案17】：

由于我尝试提交的分支是我在 master 下的子分支，我首先从存储库中删除了它（由于反向引用问题）。然后我用 push 重试，它又工作了！

注意：作为删除初始分支的一部分，我在即将执行的推送中进行了所有先前的更改，因此没有丢失任何代码。

【参考方案18】：

这取决于权限。

您可能无权直接推送到主分支（主分支、开发分支）。如果您在企业项目中，则应将自己的主题分支推送到其远程并提交合并请求（MR）。

【参考方案19】：

就我而言，远程存储库已经有一个与我正在处理的 dev 分支同名的分支。我只是重命名了分支并推送了代码。它对我有用。

git checkout -b new-branch-name
git push origin new-branch-name

【参考方案20】：

如果您真的担心任何其他方法，这些步骤可以帮助您轻松

1：Stash 你想要推送的本地分支中的更改

2：重命名您的本地分支作为您未来的备份

3：从你的遥控器创建一个同名的分支，它将包含所有更改

4：签出这个新分支作为您的新本地分支

5：在此分支中进行并保存更改

6：提交和推送