我在本地机器上进行了一些更新，将它们推送到远程存储库，现在我试图将更改拉到服务器并收到消息；
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 可以保护您免于丢失潜在的重要更改。
你有三个选择：
git commit -m "My message"
存储充当堆栈，您可以在其中推送更改，并以相反的顺序弹出它们。
要存储，请键入
git stash
进行合并，然后拉出 stash：
git stash pop
使用git reset --hard
或git checkout -t -f remote/branch
使用git checkout filename
git stash
git pull <remote name> <remote branch name> (or) switch branch
git stash apply --index
第一个命令将您的更改临时存储在stash中，并将它们从工作目录中删除。
第二个命令切换分支。
第三个命令恢复您存储在存储中的更改（该--index选项可用于确保暂存文件仍处于暂存状态）。
您可以尝试以下方法之一：
对于简单的更改，请尝试在拉动更改时在其之上重新设置基础，例如
git pull origin master -r
因此，它会在获取后将您当前的分支应用到上游分支之上。
这相当于:checkout master和fetchgitrebase origin/master命令。
这是一种潜在的危险操作模式。它改写了历史，当您已经发布了该历史时，这并不是一个好兆头。
git-rebase(1)除非您仔细阅读，否则不要使用此选项。
如果您不关心本地更改，则可以临时（强制）切换到其他分支，然后将其切换回来，例如
git checkout origin/master -f
git checkout master -f
如果您不关心本地更改，请尝试将其重置为 HEAD（原始状态），例如
git reset HEAD --hard
如果上面没有帮助，它可能是你的 git 规范化文件 ( .gitattributes) 中的规则，所以最好提交它所说的内容。或者你的文件系统不支持权限，所以你必须filemode在你的 git 配置中禁用。
试试这个
git stash save ""
并再次尝试拉
所以我遇到的情况如下：
错误：您对以下文件的本地更改将被合并覆盖：wp-content/w3tc-config/master.php 请在合并之前提交您的更改或存储它们。
除了，在那之前，是远程的：所以实际上是这样的：
远程：错误：您对以下文件的本地更改将被合并覆盖：some/file.ext 请在合并之前提交您的更改或存储它们。
发生的事情是（我认为，不是 100% 肯定的）git post receive 钩子开始运行并且由于远程服务器存储库中的移动变化而搞砸了，理论上不应该被触及。
所以我最终通过跟踪 post-receive 钩子并找到了这个，不得不去服务器上的远程存储库，并且发生了变化（这不在我的本地存储库中，实际上，说它匹配，没有更改，没有提交，最新等）所以在本地，没有更改，在服务器上，然后我做了一个git checkout -- some/file.ext，然后本地和远程存储库实际上匹配，我可以继续工作，部署。不完全确定这种情况是如何发生的，尽管数十名开发人员加上 IT 变更可能与此有关。
就我而言，我不想保留文件，所以这对我有用：
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 是强制它运行所必需的。
如果您有新创建的文件，您可以创建一个本地更改补丁，拉入远程合并并在远程合并完成后应用您的本地补丁，如下所示：
git add .
git diff --cached > mypatch.patch
git reset --hard
git pull
git apply mypatch.patch
Git 将合并更改并为未合并的更改创建 .rej 文件。
正如 Anu 所建议的，如果您在应用补丁时遇到问题，请尝试：
git apply --reject --whitespace=fix mypatch.patch
这个答案git: patch does not apply详细讨论这个问题
享受您在功能上的持续工作，并在完成后提交您的本地更改。
对我来说，这很有效：
git reset --hard
进而
git pull origin <*current branch>
之后
git checkout <*branch>
这解决了我的错误：
我在分支上：“A”
git stash
移动到主分支：
git checkout master
git pull*
回到我的分支：“A”
git checkout A
git stash pop*
对我来说，只有git reset --hard工作。
提交不是一种选择，因为没有什么可提交的。
藏匿不是一种选择，因为没有什么可以藏匿的。
看起来它可能来自排除的文件，.git/info/exclude并且已经git update-index --assume-unchanged <file>编辑了一些文件。
采用 ：
git reset --hard
然后 ：
git pull 起源大师
使用丢弃本地更改git reset --hard
就我而言，我备份然后删除了 Git 抱怨的文件，提交了，然后我终于能够签出另一个分支。
然后我替换了文件，复制回内容并继续，好像什么也没发生一样。
这可能是由 CRLF 问题引起的。
请参阅：为什么我应该在 Git 中使用 core.autocrlf=true？
使用它来拉取和强制更新：
git pull origin master
git checkout origin/master -f
我尝试了第一个答案：git stash得分最高但仍然弹出错误消息，然后我发现这篇文章提交更改而不是 stash 'Reluctant Commit'
错误信息终于消失了：
1：git add .
2：git commit -m "this is an additional commit"
3：git checkout the-other-file-name
然后它起作用了。希望这个答案有帮助。:)
如果您使用的是Git Extensions，您应该能够在Working directory如下所示的位置找到您的本地更改：
如果您没有看到任何更改，可能是因为您使用了错误的子模块。所以检查所有带有潜艇图标的项目，如下所示：
当您发现一些未提交的更改时：
选择带有 的行Working directory，导航到Diff选项卡，右键单击带有铅笔（或+或-）图标的行，选择重置以首次提交或提交或存储或任何您想要对其执行的操作。
大概
git --rebase --autostash
有助于
在使用 reset 之前，请考虑使用 revert 以便您可以随时返回。
https://www.pixelstech.net/article/1549115148-git-reset-vs-git-revert
根据要求
来源：https ://www.pixelstech.net/article/1549115148-git-reset-vs-git-revert
git reset vs git revert sonic0002 2019-02-02 08:26:39
在使用 git 等版本控制系统维护代码时，我们不可避免地需要回滚一些由于错误或临时代码还原而导致的错误提交。在这种情况下，新手开发人员会非常紧张，因为他们可能会迷失在不影响其他人的情况下应该如何回滚更改，但对于资深开发人员来说，这是他们的日常工作，他们可以向您展示不同的方式。在这篇文章中，我们将介绍开发人员经常使用的两个主要的。
它们有什么区别和对应的用例？我们将在下面详细讨论它们。git reset 假设我们有以下几个提交。
提交 A 和 B 是工作提交，但提交 C 和 D 是错误提交。现在我们要回滚到提交 B 并删除提交 C 和 D。目前 HEAD 指向提交 D 5lk4er，我们只需将 HEAD 指向提交 B a0fvf8 即可实现我们想要的。使用 git reset 命令很容易。
git reset --hard a0fvf8
执行上述命令后，HEAD 将指向提交 B。
但是现在remote origin还是有HEAD point to commit D，如果我们直接用git push推送修改，是不会更新remote repo的，需要加-f选项强制推送修改。
git push -f
这种方法的缺点是一旦重置完成，HEAD 之后的所有提交都将消失。万一有一天我们发现一些提交吃掉了好的提交并想要保留它们，那就太晚了。正因为如此，许多公司禁止使用这种方法来回滚更改。
git revert git revert的 用途是创建一个新的提交，它可以恢复以前的提交。HEAD 将指向新的还原提交。对于上面的 git reset 示例，我们需要做的只是恢复提交 D，然后恢复提交 C。
git revert 5lk4er
git revert 76sdeb
现在它创建了两个新的提交 D' 和 C'，
在上面的例子中，我们只有两个提交要恢复，所以我们可以一个一个地恢复。但是如果有很多提交要恢复怎么办？我们确实可以恢复一个范围。
git revert OLDER_COMMIT^..NEWER_COMMIT
这种方法没有git reset的缺点，它将 HEAD 指向新创建的还原提交，并且可以直接将更改推送到远程而不使用-f选项。现在让我们看一个更难的例子。假设我们有三个提交，但错误的提交是第二个提交。
使用git reset回滚提交 B不是一个好主意，因为我们需要保留提交 C，因为它是一个好的提交。现在我们可以恢复提交 C 和 B，然后使用cherry-pick再次提交 C。
从上面的解释中，我们可以发现 git reset 和git revert最大的区别在于git reset会通过在期望的提交后删除所有更改来将分支的状态重置为先前的状态，而 git revert 将重置为先前的状态通过创建新的还原提交来状态并保留原始提交。建议在企业环境中使用 git revert 而不是 git reset 。参考：https://kknews.cc/news/4najez2.html
% git status HEAD detached at 5c Changes not staged for commit：（使用“git add ...”更新将提交的内容）（使用“git restore ...”丢弃工作目录中的更改）