我只在自动化环境中遇到过这个问题，即Gitlab管道和Github动作，在发布期间，分支被自动合并和推送。对我来说，唯一有效的手动解决方案是创建一个具有相同更改的新分支，并在新分支上运行管道。

我还没有想出如何在Gitlab和Github管道永久修复它。

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

Git拉源码“你想推的分支名称” git变基 如果git rebase成功，那么很好。否则，您必须在本地解决所有合并冲突，并保持它继续，直到与remote的重基成功。 Git rebase—继续

这件事刚刚发生在我身上。

昨天我向我们的主人提出了请求。 我的同事今天正在审查它，发现它与我们的主分支不同步，所以为了帮助我，他将master合并到我的分支。 我不知道他会那样做。 然后我在本地合并master，尝试推它，但是失败了。为什么?因为我的同事合并与主人创建了一个额外的提交，我没有在本地!

解决方案:拉下我自己的分支，这样我就能获得额外的提交。然后把它推回我的远程分支。

在我的树枝上，我真的做了:

git pull
git push

由于我试图提交的分支是master下的子分支，所以我首先从存储库中删除了它(由于回溯引用问题)。然后我重新尝试推，它再次工作!

注意:作为删除初始分支的一部分，我在推送中有所有之前的更改，所以没有代码丢失。

我是这样解决问题的:

让我们假设上游分支是您派生的分支，原点是您的存储库，您想要向上游分支发送一个MR/PR。

假设您已经提交了大约四次，并且由于当前分支的尖端落后，您正在获得被拒绝的更新。

以下是我所做的

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

git rebase -i HEAD~4

您将得到一个包含选择的提交列表(在编辑器中打开)。

例子

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

to

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

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

Next

你需要把承诺藏起来。

方法如下:

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

这取决于权限。

您可能没有直接推送到主分支(master, development)的权限。如果您在一个企业项目中，您应该将自己的主题分支推到其远程并提交合并请求(MR)。