Git Pull提到我找不到的未跟踪文件

Question

我正在尝试从Git中提取错误信息：

The following untracked working tree files would be overwritten by merge:

:q
Please move or remove them before you merge.

我既找不到此文件，也不知道它可能指的是什么，为什么它以a开头：

git diff显示它为新文件

Answer 1

（虽然注释中没有足够的信息可以说明，但极大地扩展了评论；也许是答案）。

首先，请注意：这是Windows上的吗？ Windows具有名称中带有冒号的文件的“问题”。 （我尽量避免使用Windows，对此也不是很确定，但是我认为即使在那儿创建这样的文件也应该是不可能的。）其他系统也应该可以很好地处理它，并且不应神秘地隐藏它-但是，我将在下面探讨两种可能性。

另一个注意事项： git pull只是运行git fetch （从另一个Git获取提交，并将它们放入origin/master下的仓库中），然后进行git merge （将现在在origin/master的提交git merge到自己的仓库中） master ）。 我没有设置远程服务器，因此在下面，我直接使用git merge ，并在自己的存储库中使用命名的分支，而不是使用这些origin/master （它们很像分支，但在分支机构却没有）至少不是很准确-实际上是分支机构，因为Git术语很糟糕）。

查找名称奇怪的文件

您说找不到:q文件，但是（a）不要提及您使用什么工具查找文件，并且（b） 确实说git diff将名为:q的文件显示为新文件（再次没有引用实际的git diff输出，这使得很难猜测您的意思）。 这意味着您可以通过某种工具（除了正在使用的工具以外的其他工具）间接查看文件（通常只能直接显示文件）。

作为实验，我创建了一个新的存储库，并在其中创建了一些虚拟文件和一个分支。 在侧分支中，我创建并提交了两个带有“有趣”名称的文件。 一个具有四个字符名称冒号 Q 退格 退 格 键-天真的程序可以通过将:q字符串写入显示，然后将两个退格符写入到显示器，来“显示”该文件的名称，以便下一个字符覆盖冒号和小写字母- q值。 然后， 下一个文件名可能会覆盖刚刚显示的文件名。 另一个“有趣的名称”文件是冒号 Q space ，它在显示时看起来像:q没有空格，因为屏幕的大部分空间都充满了看起来完全像空格的空格。 :-)

现在，在这个特定系统上的ls命令不是那么幼稚，因此运行ls我们会得到：

$ ls
:q??    :q      README  file

显示在屏幕上，但是如果我运行ls -C | expand ls -C | expand我得到：

$ ls -C | expand
        :q      README  file

如您所见，或者也许“看不见”的措辞更好，它的名称中带有退格键的文件似乎消失了，只是在列式文件列表中占据了一个插槽。 我们确实知道它在那里！

通过git status查找名称奇怪的文件

如果现在运行git status ，它将显示以下内容：

$ git status
On branch master
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    ":q\b\b"
    :q 

nothing added to commit but untracked files present (use "git add" to track)

在这里，Git特别注意显示嵌入式退格名称：它添加了双引号并使用\\b来编码退格。 但是，用空格结尾的名字仍然很巧妙地变相：以冒号，Q，空格显示，并且“空格”看起来与没有空格的情况完全相同。

合并时Git会做什么

由于我已经在sidebr分支sidebr提交了这些文件，因此将它们合并的任何尝试都会产生：

$ git merge sidebr
error: The following untracked working tree files would be overwritten by merge:
    :q??
    :q 
Please move or remove them before you merge.
Aborting

再次，Git对退格键做了一些巧妙的处理，但尾随的空白只是简单地复制到屏幕（和Terminal窗口一样），看起来和背景一样。

从工作树中删除不需要的文件

要删除不需要的文件，我只需删除所有以冒号和q开头的文件：

$ rm :q*
$ ls
README  file

之后git merge sidebr成功：

$ git merge sidebr
<git makes me enter a merge commit message>
Merge made by the 'recursive' strategy.
 ":q\b\b" | 1 +
 :q       | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 ":q\b\b"
 create mode 100644 :q 

在下一次提交中删除不需要的文件

现在不需要的文件又回来了-毕竟，我sidebr它们提交到了sidebr分支中，专门用于解决此问题。 但是现在它们不再是未跟踪的文件，因此要删除它们，我想使用git rm而不是plain rm ，然后我也要提交删除。

在这一点上，我遇到了另一个问题：

$ git rm :q*
fatal: pathspec ':q??' did not match any files

这里发生的是，Git特别对待以冒号开头的参数。 要变通解决此问题，我通常先删除文件：

$ rm :q*

然后告诉Git更新它知道的所有文件，其中当然包括以下两个:q<otherstuff>文件：

$ git add -u

现在git status显示：

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    ":q\b\b"
    deleted:    :q 

我可以运行git commit ：

$ git commit -m 'remove icky colon-named files'
[master 1e4e9f6] remove icky colon-named files
 2 files changed, 2 deletions(-)
 delete mode 100644 ":q\b\b"
 delete mode 100644 :q 

由于您从git merge收到了同样的投诉，一旦您从工作树中实际删除了不需要的文件，您的git pull或git merge会将其作为已提交（而不是未跟踪）的文件带回，您需要提交使用上面的两步过程进行删除。

为了完整性（无需阅读本节）：为什么git rm :q*失败

还有另一种技巧，我在这里包括以供说明。 Git与名为:q<space>文件有关的问题不是空格，而是前导冒号。 这是在Git词汇表中的pathspec定义下pathspec的。

以冒号开头的pathspec具有特殊含义。 在简短形式中，前导冒号：后跟零个或多个“魔术签名”字母（可以选择由另一个冒号：终止），其余为与路径匹配的模式。 “魔术签名”由ASCII符号组成，它们既不是字母数字，全局，正则表达式特殊字符也不是冒号。 如果模式以不属于“魔术签名”符号集且不是冒号的字符开头，则可以省略终止“魔术签名”的可选冒号。

在长格式中，前导冒号：后跟一个开放的括号（一个用逗号分隔的零个或多个“魔术词”列表和一个封闭的括号），其余为与路径匹配的模式。

在这种情况下， :q<backspace><backspace>被视为：

• 开始使用pathspec magic（ :开始魔术）
• 不要魔术（ q是字母数字，并且不是一个开放的括号，因此这是简写形式，没有魔术字符）
• 使用名称q<backspace><backspace>

当然，该文件的名称不是q<backspace><backspace> ，而是:q<backspace><backspace> 。

在这里输入::q<backspace><backspace>是可行的，但是在外壳中使用:q*的要点是，很难输入退格字符，而又不能以通常的方式删除它们，所以这很困难。失败了。

使用rm :q*和git add -u使Git搜索目录，这回避了pathspec的魔力。 但是，还有一个简单的技巧：名称为:q<backspace><backspace>具有无限多种名称，其中大多数名称都不以冒号开头。 其中最简单的是./:q<backspace><backspace> 。 （其他命令包括././:q<backspace><backspace> ，依此类推，对于无数个前导./序列。）因此，我们只需让shell为我们生成这些名称即可：

git rm ./:q*

现在我们准备提交。

我使用了上面的git add -u方法，因为不管它的名字是什么，创建或提交这个名字奇怪的文件的人很可能都是:q<space>或:q<space><space>或:q<tab>或:q<newline> ，其中有许多可能，可能是git add . 或git add -A之类的东西首先将其添加到提交中。

Answer 2

在我看来，您尝试退出vi时键入：w：q而不是：wq 。 对于我来说，目前尚不清楚为什么合并会破坏此文件，但如果确实存在此文件是偶然的，则可以安全地删除它。

我不确定为什么会发现问题。 但我不明白为什么

rm :q

（在工作树根目录中）无法解决问题，如果确实您知道这是一个垃圾文件