Git rebase显示非快进

我被深深地埋在一个垃圾桶里

我是如何到达那里的：

我不是git专家。如果我缺少任何细节，请务必要求我澄清。 几天前，我运行了以下命令，将我的更改推送到远程分支

% git checkout master
% git pull
% git checkout redactor_changes <-- this is the branch that I made my changes 
% git commit -m "changes" # I added my changes previously
% git rebase master
% git push origin redactor_changes # pushed changes to remote branch

看起来这一套命令把我卷入了一个无法逃脱的漩涡

症状：

上面代码的最后一行抛出以下错误

! [rejected]        redactor_changes -> redactor_changes (non-fast-forward)
error: failed to push some refs to 'https://git.<domain>.com/web/oblog.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.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

这让我回到了标签上。这只是继续下去

---

请注意，如果我不使用master重新设置push命令的基址，则push命令可以工作，但当远程git的所有者尝试将我的分支（redactor\u更改）合并到master上时，他仍然会看到冲突。

每次在

master上重新设置
redactor\u更改
分支的基址时，您正在将后一个分支的最新更改引入前一个分支。用图表说明：

master:           A -- B -- D
redactor_changes: A -- B -- C

这个简单的图表假设您在
B
commit处分支了
master
。从那时起，您已经向
redactor\u changes
（
C
）提交了一次，其他人已经向
主分支（
D
）提交了一次。现在，如果您运行以下命令

git checkout redactor_changes
git rebase master

您将得到以下图表

master:           A -- B -- D
redactor_changes: A -- B -- D -- C'

重新定基成功地从
master
引入了新提交，但它是通过重写
redactor\u更改的历史记录来实现的。这是一件好事（可能是好事），因为这意味着审阅者可以使用您的更改快速推进
master
分支（无合并提交）。但它确实有一个副作用。您不能再将
redactor\u更改
推送到遥控器。正在尝试以下命令

git push origin redactor_changes

将向您提供您看到的错误消息

!！[拒绝]编校更改->编校更改（非快进）
错误：无法将某些引用推送到“…com/web/oblog.git”

提示：更新被拒绝，因为当前分支的提示已过期
提示：它的远程对应项

因为您重写了
redactor\u更改的历史记录
Git不再知道如何在远程分支上播放提交

% git checkout master
% git pull
% git checkout redactor_changes <-- this is the branch that I made my changes 
% git commit -m "changes" # I added my changes previously
% git rebase master
% git push origin redactor_changes # pushed changes to remote branch

解决方案：

您最可能想要的解决方案是强制将
redactor\u更改
分支转移到远程：

git checkout redactor_changes
git rebase master
git push --force redactor_changes

这样做，错误信息就会消失。这假设
redactor\u changes
是一个个人分支，您不会与任何人共享它

我还注意到您的工作流程中存在一些其他问题，例如，在已经重定基址后，将
master
合并到
redactor\u更改中。但是强制推送至少可以改善您的情况。
我看到的一个问题是，您在执行
git-rebase-master
之后立即执行了
git-merge-master
。为什么要这样做？我的意图是将更改与主控合并，使我的分支更新，然后运行rebase将分支定位到主控。你认为这可能导致所有这些问题吗？我提交的更改旨在与master合并，因为它们应该进入生产。运行上面的命令，使git将我的分支视为个人分支，当远程git的管理员试图将其和主分支合并时，还会抛出错误吗？或者，是否有可能（或太晚）删除我分支上的所有内容，例如恢复所有更改，以便我的分支与远程repo完全匹配？我可以手动保存所有文件并在以后传输更改，因为更改集没有那么大。我认为您不理解Git工作流，因为您的评论对我来说没有意义。如果您没有强制推送的权限，那么您可能不应该使用重基工作流。@printfmyname，您的后续问题都是否定的。首先，试图在中合并您的更改的协作者将得到简单的快速合并。第二，现在删除所有内容并重新开始还不算太晚，但那也会是一个漩涡，你可能逃不掉。@Jaff，我就是这么做的。一切似乎都很好。对于那些有同样问题的人，我移除了远程分支并进行了git拉取。然后，一旦我将redactor_更改重新设置为master（我也必须解决冲突），我就执行了git推送源redactor_更改。感谢Tim提供的解决方案和视觉效果。我有点担心执行一个带有强制标签的命令，即使它能把我拉到一个更安全的地方。
git checkout redactor_changes
git rebase master
git push --force redactor_changes