如果我更改文件，添加我的更改，提交它们，然后拉，Git声称我有未提交的更改。当我再次尝试提交时，我会收到“无需提交，工作树清理”的消息。
[Annas-MacBook-Pro:Project Anya$ git status
On branch master
Your branch and 'origin/master' have diverged,
and have 4 and 3 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
Annas-MacBook-Pro:Project Anya$ git pull origin master
anna@anna-git's password:
From ssh://anna-git/git/Project
* branch master -> FETCH_HEAD
error: Your local changes to the following files would be overwritten by merge:
index.html
js/app.js
sass/custom.scss
Please commit your changes or stash them before you merge.
Aborting
我确信我没有再次更改文件，但即使某些东西以某种方式改变了它们，它也不会让我再次提交它们。为什么git认为我有本地更改？我该如何解决这个问题？
答案 0 :(得分：0)
--assume-unchanged或--skip-worktree 你使用这些标志让Git骗你，以便让你更方便。但现在，谎言已经回来咬你了。
请注意，git pull只表示＆＃34;运行git fetch，然后运行第二个命令，通常是git merge＆＃34;并且错误来自git merge步骤。所以它并不完全 pull 失败;失败的合并。这很重要，因为关于它失败的原因以及如何应对的答案与使用git merge而不是使用git pull有关。 （这是我建议避免使用git pull的众多原因之一：它隐藏了太多你。当所有工作 ....时，这很好...... :-)）
这种失败有两种可能的原因，区别在于两种略有不同的不同消息。在这两种情况下，我们都可以确定您拥有文件。
以下是合并失败的关键路线：
error: Your local changes to the following files would be overwritten by merge: index.html js/app.js sass/custom.scss
作为一个重要的附注，它指的是对这些文件的本地更改，而不仅仅是＆＃34;这些本地文件＆＃34;。此错误消息的另一种形式，而不是The following untracked working tree files。如果你得到了这个错误，我们会知道一些密切相关的东西，但不完全相同。
这里是git status输出：
nothing to commit, working tree clean
这似乎很明显，这个是，考虑到第一个投诉的措辞 - 矛盾。但是有一个解释，与索引有关。
git status Git的索引是第一个近似值，您可以在其中构建下一个提交。当您大部分准备好进行提交时，修改了要修改的任何工作树文件，删除了要删除的工作树文件，并添加了您想要添加的任何新工作树文件 - 您必须执行两个进行新提交的事情：
git add）和git commit 原因是git commit从索引创建新提交，而不是从工作树创建。因此，您必须将任何新版本的文件复制到索引中，或从索引中删除任何已删除的文件。
当您运行git status时，Git会运行两个 git diff。将当前提交（称为HEAD）与索引进行比较。另一个将索引与工作树进行比较。第一个git diff告诉您已经复制到索引的内容（如果有的话），以便它在您提交的 next 提交中有所不同。第二个git diff告诉您在工作树中更改了什么（如果有的话），但不已复制到索引中，因此在此之前必须git add让它进入你的下一次提交。
第二个git diff也可以找到未跟踪的文件。未跟踪文件只是＆＃34;工作树中不在索引＆＃34;中的文件。这真的很简单：文件必须在工作树中，并且不能在索引中，以便不跟踪。
通常，当Git找到未跟踪的文件时，它会抱怨它们：你不想提交这个文件吗？不是吗？咦？嗯？你可以通过添加它们来列出它们的名字，或者在.gitignore文件中列出与它们匹配的名称模式。这使得Git闭嘴，但是没有使文件未被跟踪：这仍然是由工作树中的＆＃34;而不是索引＆＃34;。
一旦文件 在索引中，Git就会告诉您工作树文件已更新。 你不想提交这个文件吗？不是吗？咦？嗯？你可以不用.gitignore来关闭这个：文件在索引中;他们被跟踪＆＃34 ;;在.gitignore中列出它们无效。
如果你希望Git像失去的小狗一样停止抱怨，你可以运行git update-index --assume-unchanged或git update-index --skip-worktree。这告诉Git在文件的索引条目上设置一个标志位：是，可以修改此文件。但如果是，请假装它没有。然后git status不会继续说你想要提交这个文件吗？不是吗？咦？咦？
但现在谎言是个问题。
git checkout和git merge都使用 - 因此写在索引和工作树上。我在这里描述git checkout因为它更简单，但问题是一样的。在许多情况下，对于许多文件，当从一个提交移动到另一个提交时，Git不会必须在索引和工作树上写入。但是，几乎在所有情况下， 必须在索引和工作树上写入一些文件。
例如，假设您正在进行哈希ID为badbeef的提交。在该特定提交中，存在index.html的版本。现在你告诉Git检查一个不同的提交，其哈希ID为cafedad。在该特定提交中，还版本为js/app.js。但是：这些是相同的版本，还是不同的版本，js/app.js？
如果他们相同，Git可以从badbeef移动到cafedad而不会触及js/app.js。但如果没有，Git必须删除索引和工作树中的那个，并将其替换为其他提交中的js/app.js
如果js/app.js的索引和工作树版本与HEAD 的js/app.js提交版本匹配，则写入该文件没什么大不了的。它在另一个提交中：如果你想要旧版本，你可以从其他提交中获取它。 但是如果他们不匹配，那么写一下巨大的协议。这可能会破坏珍贵的文件内容。
Git告诉你的是，你正在合并的提交也具有相同的三个文件，和它有一个不同的版本那些文件比索引和工作树中的文件要多。如果您要强制Git进行合并，那么将替换这些文件的版本与这些文件的其他提交版本。因此你必须：
Please commit your changes or stash them before you merge.
但是git status什么也没说，因为你告诉它谎言。
你必须告诉Git不要骗你。如果您设置--assume-unchanged，请使用--no-assume-unchanged清除它。如果您设置--skip-worktree，请使用--no-skip-worktree清除它。现在git status将向您展示现实。
当然，您首先要设置这些内容是有原因的。所以现在你必须解决那个问题。解决 ，提交或存储您的文件，并合并，然后您就完成了。