我在本地机器上做了一些更新,将它们推送到远程存储库,现在我试图将更改拉到服务器上,我得到了消息;

error: Your local changes to the following files would be overwritten by merge:
wp-content/w3tc-config/master.php
Please, commit your changes or stash them before you can merge.

所以我跑了,

git checkout -- wp-content/w3tc-config/master.php

再试一次,我得到了同样的信息。我假设w3tc更改了服务器上配置文件中的一些内容。我不关心本地副本或远程副本是否在服务器上(我认为远程副本是最好的),我只是希望能够合并我的其余更改(插件更新)。

什么好主意吗?


当前回答

警告:这将删除未跟踪的文件,所以它不是这个问题的一个很好的答案。

以我为例,我不想保留这些文件,所以这对我来说很有效:

Git 2.11及更新版本:

git clean  -d  -fx .

较旧的 Git:

git clean  -d  -fx ""

参考:http://www.kernel.org/pub/software/scm/git/docs/git-clean.html

-x意味着被忽略的文件以及git不知道的文件也会被删除。 -d表示除未跟踪的文件外,还删除未跟踪的目录。 -f命令用于强制运行。

其他回答

在我的NestJS项目中,我在.env文件中遇到了类似的问题。

尝试了很多方法,包括本页上的方法。

最后,在剪贴板上复制。env的内容,删除文件,git拉起工作!

重新创建.env并将内容粘贴回来。

如果有多个文件,只需将它们临时移出git回购目录,然后在拉出更改后将它们移回。

可能

git --rebase --autostash

将有助于

您不能与本地修改合并。Git保护您避免丢失潜在的重要更改。

你有三个选择:

使用以下命令提交更改 git commit -m我的信息 隐藏它。 存储就像一个堆栈,您可以在其中推送更改,并以相反的顺序弹出更改。 储存,键入 git藏 做合并,然后取出藏物: Git隐藏pop 丢弃局部更改 使用git重置——很难 或者git checkout -t -f remote/branch 或者:放弃特定文件的本地更改 使用git签出文件名

要在解决此问题时记录新创建的文件:

如果你有新创建的文件,你可以创建一个本地更改的补丁,拉入远程合并,并在远程合并完成后应用你的本地补丁,如下所示:

进行本地更改。(不要承诺)。为新创建的文件创建补丁需要分段(因为它们仍然无法跟踪)

转到添加 。

创建一个补丁来保存记录

Git diff——缓存> myppatch .patch

丢弃本地更改并删除新的本地文件

Git重置——很难

把变化

git pull

应用补丁

去应用mypatch.patch

Git将合并更改,并为未合并的更改创建.rej文件。

根据Anu的建议,如果你在应用补丁时有问题,试试:

Git apply——reject——whitespace=fix myppatch .patch 本回答git: patch does not apply详细讨论了这个问题

享受您在特性上的持续工作,完成后提交您的局部更改。

我遇到的情况是这样的:

错误:您对以下文件的本地更改将被merge覆盖: wp-content / w3tc-config / master.php 请在合并之前提交您的更改或隐藏它们。

除了,在那之前,是遥远的: 实际上是这样的:

您对以下文件的本地更改将被merge覆盖: 一些/ file.ext 请在合并之前提交您的更改或隐藏它们。

发生的事情是(我认为,不是100%肯定)git post receive钩子开始运行,由于远程服务器存储库中的移动变化而搞砸了,理论上,不应该触及。

So what I ended up doing by tracing through the post-receive hook and finding this, was having to go to the remote repository on the server, and there was the change (which wasn't on my local repository, which, in fact, said that it matched, no changes, nothing to commit, up to date, etc.) So while on the local, there were no changes, on the server, I then did a git checkout -- some/file.ext and then the local and remote repositories actually matched and I could continue to work, and deploy. Not entirely sure how this situation occurred, though a couple dozen developers plus IT changes may had something to do with it.