Question

所以我重新建立了一个反对主人的分支。但是，

git push --set-upstream origin MyBranch

我得到了

 ! [rejected]        MyBranch -> MyBranch (non-fast-forward)
 error: failed to push some refs to 'https://mygit@bitbucket.org/mygit/myproject.git'
 hint: Updates were rejected because the tip of your current branch is behind
 hint: its remote counterpart. Integrate the remote changes (e.g.
 hint: 'git pull ...') before pushing again.

所以，好的。再次重新定位。完成没有问题。然后

 git pull

 * branch            HEAD       -> FETCH_HEAD

好的，已经是最新的

git push --set-upstream origin MyBranch

再次，错误。我可以强迫推，但我不喜欢丢失东西的风险，说实话，我真的想知道这个令人讨厌的问题的正确解决方案，即使我玩规则手册也似乎发生了。

Answer 1

根据您的描述，我将尝试对可能发生的事情进行有根据的猜测。

Git拒绝将您的重新提交的提交推送到上游分支（<input data-bind="event: { change: value_changed }, value: saved_value, valueUpdate: 'afterkeydown'" />），因为它们具有与已存在的不同的提交哈希。它们之所以不同，是因为您在不同的提交之上重新设置了本地提交，而不是上游分支中的提交

。

问题

以下是我认为您的情况可能如下的示例：

origin/MyBranch

Local Origin A---B---C---F (master) A---B---C---F (master) \ \ D'---E' (MyBranch) D---E (MyBranch)中的提交D和E最初位于origin/MyBranch的{{1}}之上。然后C成为master的新F。

当您在HEAD中master时，您在本地仓库中获得了新的提交git pull。

您在master之上重新F，现在MyBranch，并将master和F的提交哈希更改为{{1} }和D。

发布E拒绝覆盖提交，因为Git将其视为不同的提交而不是D'中的提交，这些提交仍然基于E'的顶部

（可能的）解决方案

如果你是唯一一个git push origin MyBranch工作的人，或者你可以轻松地与那些可能有兴趣在该分支机构工作的任何人进行沟通，我会说只是强制推动你的重新提交。同样，假设在此期间没有其他人将提交推送到origin，你就不会失去任何东西。

如果这根本不能反映您的情况，请随时忽略此建议，如果可能，请添加有关该问题的更多详细信息。

再一次：快进错误

1 个答案:

问题

（可能的）解决方案