我的存储库中有一个符号链接目录，该目录链接到文件系统上其他位置的文件。无论出于何种原因，符号链接都会不时中断，并变成一个常规的空文件夹。因此，我删除了空文件夹，并使用ln -s ../../ ext重新创建了符号链接，当我可以浏览该文件夹并查看其内容时，它似乎起作用了。但是，当我运行git status时，似乎所有ext文件夹中应该可见的文件都丢失了。如何让git在符号链接目录中再次看到它们？
顺便说一下，这是在Ubuntu 18上。
您的设置很奇怪，因为Git没有follow符号链接，它只是stores个符号链接。
即，如果您具有符号链接ext -> ../..并运行git add ext，则Git在索引中创建模式为120000（符号链接）的条目以存储Blob内容../..。提交将创建一个提交，该提取被提取后将创建指向ext的符号链接../..。 Git 将不会在存储此符号链接时存储任何文件内部 ext。
另一方面，如果您有一个包含名为ext/foo和ext/bar的文件的现有提交，并且在此提交时克隆了此存储库，或者将该提交提取到了一个新的，否则为空的工作树Git中。将会看到，为了写入名为ext/foo和ext/bar的文件，您的操作系统要求ext作为目录存在。因此，它将create空的directory ext，然后将在其中创建您的操作系统所需的文件foo和bar，以便创建仅被命名为[ C0]和ext/foo。这两个名称ext/bar和ext/foo现在将在索引中，以便您进行的下一次提交也将包含这两个文件。
听起来像您：
ext/bar？]；git clone --no-checkout的工作树中手动创建了一个符号链接，指向某个现有目录（可能在其中包含一些文件）；ext创建git checkout和ext/foo，而无需首先删除符号链接ext/bar并将其替换为目录ext。这不是受支持的操作模式1，当它出错时，您应该不会感到惊讶。
1导致安全问题：Git的意思是不要在工作树区域之外写入任何文件，并且将指向该工作树之外的目录的符号链接写入文件“之下”这发生。而不是仔细限制符号链接的使用，Git通常不会首先存储“超出”任何链接的文件-尽管通过仔细操作索引以及在OS级别上，您可能会仔细地存储文件系统工作树驻留，以手动欺骗Git。