Git 克隆导致已删除和未跟踪的文件

Question

我是 Git 的新用户。

我刚刚为 Windows (10) 安装了 Git (2.9.3)，然后我打开了 git-bash 并做了一个git clone <remoteURL> 。 使用远程存储库的整个副本创建一个新文件夹，这很好。 但是后来我运行了git status ，我得到了大量deleted的文件（我想是刚刚复制的所有文件）准备to be committed ，并且存储库文件夹下的三个主要文件夹untracked 。 deleted的文件实际上存在于我的驱动器上！

我很确定我的 git 状态应该是干净的。 怎么了？

关于已删除的文件没有帮助（我没有使用checkout ），关于未跟踪的文件也没有帮助（我没有使用 Mac OS）。

Answer 1

我正在检索一个路径很长的大型项目。 我忘了设置 Git 以使用长路径：

git config --global core.longpaths true

在此之后，克隆进行得很顺利，状态也很干净。

Answer 2

听起来您以某种方式加载了一个空索引。 使用命令git read-tree --empty发生这种情况的正常方式，但这不是您作为 git 新用户通常使用/知道的。

也许克隆出了点问题。 不过应该不难修复，只需运行

git reset

并且索引应该恢复到最新提交的内容。

Answer 3

这个问题不仅让“对 git 不熟悉”的 OP 感到困惑。 它也吓坏了我，一个相当大的 git verteran。 :-)

感谢此处其他答案的提示，我意识到这是由 git 引起的，它碰巧无法检出某些名称包含当前文件系统和/或操作系统上不受支持的字符的文件。 例如，当我克隆 github wiki 存储库时，我遇到了同样的错误，一些 wiki 页面的文件名中碰巧包含一个: ，它们可以在我的 Linux 机器上很好地克隆，但是（事后看来）显然不是我的 Windows 盒子。

了解根本原因使我们能够自信地决定如何/是否解决此问题：

• 我们可以通过将那些有问题的文件名重命名为更短和/或仅包含通常的字母表来修复它。
• 或者，从技术上讲，我们根本不必修复它。 如果那些有问题的文件名在他们的目标平台上没有问题，并且我们正在处理这个 repo 的其他一些内容，我们可以像往常一样继续我们的工作； 我们只需要记住不要将那些丢失的文件作为删除提交。 （去过那里，做到了；不要在家里尝试这个。）

Answer 4

如果您在 Windows 上遇到问题，可能会根据这些禁用字符检查您的文件名：

< （小于）
> （大于）
：（冒号）
" （双引号）
/ （正斜杠）
\\（反斜杠）
| （垂直条或管）
? （问号）
* （星号）

或使用以下保留字之一或其中之一紧跟扩展名命名的文件： CON、PRN、AUX、NUL、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、LPT1、LPT2、 LPT3、LPT4、LPT5、LPT6、LPT7、LPT8 和 LPT9。

可以在此处找到更多详细信息。

Answer 5

如果您最终到达这里并且 longpath 属性不起作用并且您在 Windows 上运行并使用 Git Bash，那么您可能会在 Windows 中使用保留关键字的文件。 即，我有包含nul文件，这些文件在克隆后被删除。 找了半天发现是这个保留关键字的东西。

解决方案只是重命名文件（在您可以创建它的其他机器/操作系统上）。 推送它，然后在您的 Windows 机器上重做克隆操作。

Answer 6

就我而言，我在 Mac 上的一个不区分大小写的文件系统中克隆了 repo，但是该 repo 包含一个名为Config的文件和一个名为config的目录，文件系统将其视为同一件事。 因此，在克隆时，它显示文件Config已被删除。

修复是在区分大小写的文件系统上克隆 repo。

Answer 7

也可以是文件名中的不可见字符，请在其他系统上查看 ;)

Answer 8

我在 windows 10 上遇到了类似的问题，我检查了其他 windows 以及 git 工作正常的地方，我的 git 版本是 2.24.xx。 我安装了 git 2.16.x 的旧版本，它解决了问题。 试试看，让你知道

Answer 9

将某些文件显示为已修改的行为可能与行尾设置和使用的多个客户端有关。 每个操作系统都以自己的方式处理行尾。 因此，如果您正在处理在多个操作系统中编辑文件的存储库，您可能会看到意想不到的结果

以下命令将永久解决问题

git 配置 --global core.autocrlf 输入