Git 非快进被拒绝

Git non-fast-forward rejected

提问by rynmrtn

I feel like this question has been asked many times, but the solution is typically "I deleted the directory and re-did my work with a fresh checkout." I did a commit and push but realized that I referred to the wrong ticket number in the commit message. So I looked on SO for a quick solutionand ended up typing the following into the terminal:

我觉得这个问题已经被问过很多次了，但解决方案通常是“我删除了目录并用新的结帐重新完成了我的工作。” 我做了一次提交和推送，但意识到我在提交消息中引用了错误的票号。所以我在 SO 上寻找一个快速解决方案，最终在终端中输入以下内容：

$ git reset --soft HEAD^
$ git commit -m "... correct message ..."

The only problem is I am getting the following error message:

唯一的问题是我收到以下错误消息：

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

I am using the git-flow model and am working on the develop branch. How can I merge things back in to make git happy again?

我正在使用 git-flow 模型并且正在开发分支上工作。我怎样才能把东西合并回来让 git 再次开心？

采纳答案by Alan Haggai Alavi

Force git push:

力git push：

git push origin +develop

回答by Brian Campbell

If you push a commit to the server, and then rewrite that commit locally (with git reset, git rebase, git filter-branch, or any other history manipulation), and then pushed that rewritten commit back up to the server, you will screw up anyone else who had pulled. Here's an example; say you have committed A, and pushed it to the server.

如果您将提交推送到服务器，然后在本地重写该提交（使用git reset、git rebase、git filter-branch或任何其他历史操作），然后将重写的提交推送回服务器，那么您将搞砸其他任何已提交的提交。这是一个例子；假设您已提交 A，并将其推送到服务器。

-*-*-A <-- master

-*-*-A <-- origin/master

Now you decide to rewrite A, in the way you mentioned, resetting and re-committing. Note that this leaves a dangling commit, A, which will eventually be garbage collected as it is not reachable.

现在您决定按照您提到的方式重写 A，重置并重新提交。请注意，这会留下一个悬空提交，A，最终将被垃圾收集，因为它无法访问。

-*-*-A
    \
     A' <-- master

-*-*-A  <-- origin/master

If someone else, let's say Fred, pulls down masterfrom the server while you're doing this, they will have a reference to A, which they might start working from:

如果其他人，例如 Fred，master在您执行此操作时从服务器拉下，他们将拥有对 A 的引用，他们可能会从该引用开始工作：

-*-*-A' <-- master

-*-*-A  <-- origin/master

-*-*-A-B <-- fred/master

Now if you were able to push your A' to origin/master, which would create a non-fast-forward, it wouldn't have A in its history. So if Fred tried to pull again, he'd suddenly have to merge, and would re-introduce the A commit:

现在，如果您能够将 A' 推送到 origin/master，这将创建非快进，那么它的历史记录中就不会包含 A。因此，如果 Fred 再次尝试 pull，他将突然不得不合并，并且会重新引入 A 提交：

-*-*-A' <-- master

-*-*-A  <-- origin/master

-*-*-A-B-\ 
    \     * <-- fred/master
     A'--/

If Fred happens to notice this, then he could do a rebase, which would prevent commit A from reappearing again. But he'd have to notice this, and remember to do this; and if you have more than one person who pulled A down, they would all have to rebase in order to avoid getting the extra A commit in the tree.

如果 Fred 碰巧注意到了这一点，那么他可以进行 rebase，这将防止提交 A 再次出现。但他必须注意这一点，并记住这样做；如果你有不止一个人把 A 拉下来，他们都必须 rebase 以避免在树中获得额外的 A 提交。

So, it's generally not a good idea to change history on a repo that other people pull from. If, however, you happen to know that no one else is pulling from that repo (for instance, it's your own private repo, or you only have one other developer working on the project who you can coordinate with easily), then you can forcibly update by running:

因此，更改其他人从中提取的存储库的历史记录通常不是一个好主意。但是，如果您碰巧知道没有其他人从该存储库中提取（例如，它是您自己的私有存储库，或者您只有一个可以轻松协调的其他开发人员在处理该项目），那么您可以强行通过运行更新：

git push -f

or

或者

git push origin +master

These will both ignore the check for a non-fast-forward push, and update what's on the server to your new A' revision, abandoning the A revision so it will eventually be garbage collected.

这些都将忽略对非快进推送的检查，并将服务器上的内容更新为新的 A' 修订版，放弃 A 修订版，因此最终将被垃圾收集。

It's possible that force pushes are entirely disabled with the receive.denyNonFastForwardsconfig option. This option is enabled by default on shared repositories. In that case, if you really, really want to force a push, the best option is to delete the branch and re-create it, with git push origin :master; git push origin master:master. However, the denyNonFastForwardsoption is enabled for a reason, which is described above; on a shared repository, it means that now everyone who uses it needs to ensure that they rebase onto the new history.

使用receive.denyNonFastForwardsconfig 选项可能会完全禁用强制推送。默认情况下，此选项在共享存储库上启用。在这种情况下，如果你真的、真的想强制推送，最好的选择是删除分支并重新创建它，使用git push origin :master; git push origin master:master. 但是，denyNonFastForwards启用该选项是有原因的，如上所述；在共享存储库上，这意味着现在使用它的每个人都需要确保他们重新建立新的历史记录。

On a shared repository, it is generally better to just push new commits on top that fix whatever problem you have; you can use git revertto generate commits that will undo the changes of previous commits.

在共享存储库中，通常最好将新提交推送到顶部以解决您遇到的任何问题；您可以git revert用来生成将撤消先前提交更改的提交。

回答by Tony

You might have to do a git pull, which MAY auto merge stuff for you. Then you can commit again. If you have conflicts, it'll prompt you to resolve them.

你可能需要做一个git pull，它可以为你自动合并东西。然后你可以再次提交。如果您有冲突，它会提示您解决它们。

Keep in mind, you have to specify which branch to pull from if you haven't updated your gitconfig to specify...

请记住，如果您尚未更新 gitconfig 以指定要从哪个分支中提取，则必须指定...

For example:

例如：

git pull origin develop:develop

回答by Nguyen Minh Binh

I was using EGit and I faced this issue also. Just tried to rebasethe current branch and It worked.

我正在使用 EGit，我也遇到了这个问题。刚刚尝试到rebase当前分支并且它起作用了。