我在本地机器上做了一些更新，将它们推送到远程存储库，现在我试图将更改拉到服务器上，我得到了消息;
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 stash git pull pull origin << branch >
如有需要:
Git stash应用
其他回答
您不能与本地修改合并。Git保护您避免丢失潜在的重要更改。
你有三个选择:
使用以下命令提交更改 git commit -m我的信息 隐藏它。 存储就像一个堆栈，您可以在其中推送更改，并以相反的顺序弹出更改。 储存，键入 git藏 做合并，然后取出藏物: Git隐藏pop 丢弃局部更改 使用git重置——很难 或者git checkout -t -f remote/branch 或者:放弃特定文件的本地更改 使用git签出文件名
您可以尝试以下方法之一:
变基
对于简单的更改，尝试在它的基础上重新调整，同时拖动更改，例如。
git pull origin master -r
所以它会在取回后把你当前的分支应用到上游的分支上。
这相当于:checkout master, fetch和rebase origin/master git命令。
这是一种潜在危险的操作方式。它重写了历史，这不是一个好兆头，因为你已经出版了那段历史。除非你仔细阅读了git-rebase(1)，否则不要使用这个选项。
结帐
如果你不关心你的局部变化，你可以暂时切换到其他分支(强制)，然后切换回来，例如。
git checkout origin/master -f
git checkout master -f
重置
如果您不关心您的本地更改，尝试将其重置为HEAD(原始状态)，例如。
git reset HEAD --hard
如果上面没有帮助，它可能是你的git规范化文件(.gitattributes)中的规则，所以最好提交它所说的。或者你的文件系统不支持权限，所以你必须在git配置中禁用filemode。
相关:我如何强制“git拉”覆盖本地文件?
如果你在你的任何文件做了更改;
转到添加 。
然后;
Git commit -m "your message"
在此之后，你可以成功地从你的回购中获取或推入。
对我来说，这很有效:
Git重置——很难
然后
Git拉原点<*当前分支>
在那之后
Git checkout <*branch>
我遇到的情况是这样的:
错误:您对以下文件的本地更改将被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.
