Git 非快进拒绝
我觉得这个问题已经被问过很多次了，但解决方案通常是“我删除了目录并通过新的签出重新完成了工作”。我进行了提交并推送，但意识到我在提交消息中引用了错误的票号。所以我寻找一个快速的 解决方案 并最终在终端中输入以下内容：
$ git reset --soft HEAD^
$ git commit -m "... correct 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.
我正在使用 git-flow 模型并正在开发分支上工作。我怎样才能将东西合并回去，让 git 再次高兴起来？
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 solution and ended up typing the following into the terminal:
$ 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您将提交推送到服务器，然后在本地重写该提交（使用
git reset< /code>,git rebase, <一个href="https://git-scm.com/docs/git-filter-branch" rel="noreferrer">git filter-branch或任何其他历史记录操作），然后将重写的提交推回服务器，您将搞砸其他拉取的人。这是一个例子；假设您已提交 A，并将其推送到服务器。现在你决定按照你提到的方式重写A，重置并重新提交。请注意，这会留下一个悬空提交 A，它最终将被垃圾回收，因为它无法访问。
-*-*-A \ A' <-- master -*-*-A <-- origin/master如果其他人（比如说 Fred）在您执行此操作时从服务器拉下
master，他们将获得对 A 的引用，他们可能会从 A 开始工作：现在，如果您能够推送你的 A' 到 origin/master，这将创建一个非快进，它的历史中不会有 A。因此，如果 Fred 尝试再次拉取，他突然必须合并，并重新引入 A 提交：
-*-*-A' <-- master -*-*-A <-- origin/master -*-*-A-B-\ \ * <-- fred/master A'--/如果 Fred 碰巧注意到这一点，那么他可以进行变基，这将防止提交 A 再次重新出现。但他必须注意到这一点，并记住这样做；如果有多个人拉下了 A，他们都必须重新设置基点以避免在树中获得额外的 A 提交。
因此，改变其他人从中提取的存储库的历史通常不是一个好主意。但是，如果您碰巧知道没有其他人从该存储库中提取数据（例如，这是您自己的私有存储库，或者您只有一名其他开发人员在该项目上工作，您可以轻松地与他协调），那么您可以强制update by running:
或
这些都将忽略对非快进推送的检查，并将服务器上的内容更新为新的 A' 修订版，放弃 A 修订版，因此它最终将被垃圾收集。
使用
receive.denyNonFastForwards配置选项可能会完全禁用强制推送。默认情况下，此选项在共享存储库上启用。在这种情况下，如果您真的非常想强制推送，最好的选择是删除分支并重新创建它，使用 git push origin :master; git push origin master:master。但是，启用denyNonFastForwards选项是有原因的，如上所述；在共享存储库上，这意味着现在使用它的每个人都需要确保他们重新建立在新历史记录上。在共享存储库上，通常最好将新的提交推送到顶部来解决您遇到的任何问题；您可以使用
git revert生成将撤消先前提交的更改。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.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' <-- master -*-*-A <-- origin/masterIf 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: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' <-- 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.
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:
or
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.
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, withgit push origin :master; git push origin master:master. However, thedenyNonFastForwardsoption 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.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推送：Force
git push:您可能需要执行 git pull，这可能会自动为您合并内容。然后你可以再次提交。如果您有冲突，它会提示您解决它们。
请记住，如果您尚未更新 gitconfig 来指定，则必须指定要从哪个分支拉取...
例如：
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.Keep in mind, you have to specify which branch to pull from if you haven't updated your gitconfig to specify...
For example:
我正在使用 EGit，我也遇到了这个问题。只是尝试
rebase当前分支并且它起作用了。I was using EGit and I faced this issue also. Just tried to
rebasethe current branch and It worked.