更确切地说，我相信“git clone”会成功，但会立即删除我生成的本地仓库中的所有文件。类似的问题可以在here找到，但是我想不出一种方法可以将我在问题上的转变作为答案，所以我就是这样。
以下是我的方案细节的概述：
我在github上有一个存储库。我可以像任何人期望的那样在Ubuntu 12.04上使用git克隆这个存储库。当我尝试克隆wiki时会出现问题（github通过https://github.com/<owner>/<repository>.wiki.git使其可访问）。我生成的本地副本为空。运行“git status”后，我注意到克隆后，某个实体立即删除了回购的内容。
在分支主机上
要提交的更改：
（使用“git reset HEAD ...”取消暂停）
已删除：＆lt; filename＆gt;
...等我的wiki中的所有其他页面。
“git branch -a”对我来说和其他人一样：
*主
遥控器/原产地/ HEAD - ＆gt;原点/主
遥控/原点/主
更新1
确实我没有意识到暂存区域和工作目录之间的区别，但似乎不是问题。另一方面，它可能揭示了更多的错误。
我忘了提到当我第一次克隆存储库时，我收到消息“无法统计＆lt; long_filename＆gt;：文件名太长”
当我运行“git reset”时，所有删除都列在“重置后的未分级更改：”下。奇怪的是＆lt; long_filename＆gt;它被列为合并而不是删除。但是，重置后我克隆到的目录中没有文件可见。
更新2
我可以通过克隆文件夹中的gitk查看应该存在的所有wiki条目，但我确信文件在我的文件系统的任何地方都不以原始格式存在，否则“find / -name＆lt;文件名＆gt; 2＆gt; / dev / null“应该返回一些有用的输出。
更新3
显然我的一个文件名太长了，无法管理git。克隆后再次检出repo它得到了所有文件，但是那个：
error: unable to create file <filename>.md (File name too long)
答案 0 :(得分：1)
请注意，除了静默失败之外，如果在克隆之前创建（并且不是由克隆创建），那么您的空文件夹也将被删除。
在您的情况下，失败是因为文件名太长
但是，更一般地说，只要它是一个空目录，即使这个目录存在，也允许“git clone $there $her e”，但命令不正确
在操作失败时将其移除
该部分已通过Git 2.16.x / 2.17（2018年第一季度）修复
commit d45420c，见commit f9e377a，commit 8486b84，commit a4c4efd，Jeff King (peff)（2018年1月2日）。
（由Junio C Hamano -- gitster --合并于commit addd37c，2018年1月23日）
clone：不要清理我们没有创建的目录曾几何时，
git-clone会拒绝写入它本身不创建的目录。因此，失败克隆的清理例程可以完全删除git和worktree目录。在55892d2中（允许克隆到现有的空目录， 2009-01-11，Git v1.6.2-rc0），我们学会了写入现有目录。 这意味着：
mkdir foo git clone will-fail foo最终删除
foo这不是一个巨大的灾难，因为根据定义foo必须是空的 但它有点令人困惑;我们应该保留文件系统。
答案 1 :(得分：0)
您可能不熟悉暂存区和工作目录之间的区别。
如果所有文件显示为已删除，则表示暂存区域与工作目录之间存在差异;特别;这些文件位于暂存区域，但不在您的工作目录中。
只需git reset。
答案 2 :(得分：0)
git checkout .应该丢弃自上次提交以来的所有本地更改，将您恢复为干净状态。
答案 3 :(得分：0)
在OSX Mountain Lion上，我遇到了错误
error: Untracked working tree file '.DS_Store' would be overwritten by merge.
显然，令人生气的.DS_Store文件创建了我的OSX的查找程序在我试图克隆的远程存储库中。这是因为我在更新主计算机上的.gitignore文件之前最初推送了项目。
在git克隆到我的辅助计算机之前从远程存储库中删除.DS_Store为我修复了这个问题。这就是我从主计算机上做到的方式：
$ git rm .DS_Store
$ git commit -m "removed .DS_Store"
$ git push