Git 克隆导致已删除和未跟踪的文件
Git clone leads to deleted & untracked files
我是 Git 的新手。
我刚刚为 Windows (10) 安装了 Git (2.9.3)，然后我打开 git-bash 并做了一个 git clone <remoteURL> .使用远程存储库的整个副本创建一个新文件夹，这很好。但是后来我 运行 一个 git status 并且我得到了大量的 deleted 文件（我想所有刚刚复制的文件）准备就绪 to be committed，以及下面的三个主要文件夹存储库文件夹是 untracked。 deleted 文件实际上存在于我的驱动器上！
我很确定我的 git 状态应该是干净的。发生了什么事？
This about deleted files didn't help (I didn't use checkout), neither did this 关于未跟踪的文件（我没有使用 Mac OS）。
听起来您似乎以某种方式加载了一个空索引。使用命令 git read-tree --empty 时通常会发生这种情况，但作为 git.
的新用户，您通常 use/know 不会这样做
克隆可能出了点问题。不过修复应该不难，只是 运行
git reset
并且索引应该恢复到最新提交的内容。
我正在检索一个路径很长的大型项目。我忘记设置 Git 以使用长路径：
git config --global core.longpaths true
此后，克隆顺利，状态干净。
也可以是文件名中的不可见字符，在其他系统上查看;)
这个问题不仅困扰 "is new to git" 的 OP。它也吓坏了我，一个相当 git 的老手。 :-)
感谢这里其他答案的提示，我意识到这是由于 git 恰好无法检出当前文件系统 and/or 中某些名称包含不受支持字符的文件 OS。例如，我在克隆 github wiki 存储库时遇到了同样的错误，一些 wiki 页面恰好在其文件名中包含 :，它们可以很好地克隆到我的 Linux 框，但（事后看来）显然不在我的 Windows 框上。
了解根本原因让我们有信心决定 how/whether 我们解决这个问题：
- 我们可以通过将那些有问题的文件名重命名为更短的 and/or 仅包含常用字母表来修复它。
- 或者，从技术上讲，我们根本不需要修复它。如果那些有问题的文件名在他们的目标平台上没有问题，并且我们正在处理这个 repo 的一些其他内容，我们可以像往常一样继续我们的工作；我们只需要记住不要将那些丢失的文件作为删除提交。 （去过那里，做过那个；不要在家里尝试这个。）
万一你在这里结束并且长路径 属性 没有工作并且你 运行 在 Windows 上使用 Git Bash 你可能有Windows 中使用保留关键字的文件。即，我的文件中有 nul，克隆后这些文件被删除了。找了半天发现就是这个保留关键字的东西
解决方案是简单地重命名文件（在您的另一台机器上/OS 您可以创建它的地方）。推送它，然后在您的 Windows 机器上重做克隆操作。
我遇到了与 windows 10 类似的问题，我检查了其他 windows 以及 git 工作正常的地方，我的 git 版本是 2.24.xx。我安装了 git 旧版本的 git 2.16.x，它解决了问题。试一试，让大家知道
在我的例子中，我在 Mac 上的一个不区分大小写的文件系统中克隆了 repo，但是 repo 包含一个名为 Config 的文件和一个名为 config 的目录，其中文件系统被认为是同一件事。因此，在克隆时，它显示文件 Config 已被删除。
解决方法是在区分大小写的文件系统上克隆存储库。
如果您在 Windows 上遇到问题，可能会根据这些禁用字符检查您的文件名：
<（小于）
>（大于）
:（冒号）
"（双引号）
/（正斜杠）
\（反斜杠）
|（竖线或管道）
？ （问号）
*（星号）
或使用以下保留字之一或紧跟扩展名的其中之一命名的文件：
CON、PRN、AUX、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。
可以找到更多详细信息 here。
我是 Git 的新手。
我刚刚为 Windows (10) 安装了 Git (2.9.3)，然后我打开 git-bash 并做了一个 git clone <remoteURL> .使用远程存储库的整个副本创建一个新文件夹，这很好。但是后来我 运行 一个 git status 并且我得到了大量的 deleted 文件（我想所有刚刚复制的文件）准备就绪 to be committed，以及下面的三个主要文件夹存储库文件夹是 untracked。 deleted 文件实际上存在于我的驱动器上！
我很确定我的 git 状态应该是干净的。发生了什么事？
This about deleted files didn't help (I didn't use checkout), neither did this 关于未跟踪的文件（我没有使用 Mac OS）。
听起来您似乎以某种方式加载了一个空索引。使用命令 git read-tree --empty 时通常会发生这种情况，但作为 git.
克隆可能出了点问题。不过修复应该不难，只是 运行
git reset
并且索引应该恢复到最新提交的内容。
我正在检索一个路径很长的大型项目。我忘记设置 Git 以使用长路径：
git config --global core.longpaths true
此后，克隆顺利，状态干净。
也可以是文件名中的不可见字符，在其他系统上查看;)
这个问题不仅困扰 "is new to git" 的 OP。它也吓坏了我，一个相当 git 的老手。 :-)
感谢这里其他答案的提示，我意识到这是由于 git 恰好无法检出当前文件系统 and/or 中某些名称包含不受支持字符的文件 OS。例如，我在克隆 github wiki 存储库时遇到了同样的错误，一些 wiki 页面恰好在其文件名中包含 :，它们可以很好地克隆到我的 Linux 框，但（事后看来）显然不在我的 Windows 框上。
了解根本原因让我们有信心决定 how/whether 我们解决这个问题：
- 我们可以通过将那些有问题的文件名重命名为更短的 and/or 仅包含常用字母表来修复它。
- 或者，从技术上讲，我们根本不需要修复它。如果那些有问题的文件名在他们的目标平台上没有问题，并且我们正在处理这个 repo 的一些其他内容，我们可以像往常一样继续我们的工作；我们只需要记住不要将那些丢失的文件作为删除提交。 （去过那里，做过那个；不要在家里尝试这个。）
万一你在这里结束并且长路径 属性 没有工作并且你 运行 在 Windows 上使用 Git Bash 你可能有Windows 中使用保留关键字的文件。即，我的文件中有 nul，克隆后这些文件被删除了。找了半天发现就是这个保留关键字的东西
解决方案是简单地重命名文件（在您的另一台机器上/OS 您可以创建它的地方）。推送它，然后在您的 Windows 机器上重做克隆操作。
我遇到了与 windows 10 类似的问题，我检查了其他 windows 以及 git 工作正常的地方，我的 git 版本是 2.24.xx。我安装了 git 旧版本的 git 2.16.x，它解决了问题。试一试，让大家知道
在我的例子中，我在 Mac 上的一个不区分大小写的文件系统中克隆了 repo，但是 repo 包含一个名为 Config 的文件和一个名为 config 的目录，其中文件系统被认为是同一件事。因此，在克隆时，它显示文件 Config 已被删除。
解决方法是在区分大小写的文件系统上克隆存储库。
如果您在 Windows 上遇到问题，可能会根据这些禁用字符检查您的文件名：
<（小于）
>（大于）
:（冒号）
"（双引号）
/（正斜杠）
\（反斜杠）
|（竖线或管道）
？ （问号）
*（星号）
或使用以下保留字之一或紧跟扩展名的其中之一命名的文件： CON、PRN、AUX、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。
可以找到更多详细信息 here。