这个问题似乎不完整。在这种情况下，git clone 的输出应该如下所示:
<some errors specific to your situation here>
...
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'
首先，需要了解上述“fatal：…”消息中特定错误的情况，以及如何解决它们。其次，可以按照说明运行“git status”命令查看检出了什么，然后尝试“git checkout -f HEAD”命令来修复它。
我见过一些导致“warning: Clone succeeded, but checkout failed.”警告的原因，包括：
- 存储库包含符号链接，并且您想要检出的文件系统不支持符号链接。下面提供的替代方法可能会有所帮助，使用GitHub存储库的zip。
- 存储库包含某些深度目录层次结构，当前目录级别的检出结果是太长的路径，因此本地文件系统不支持。尝试对您可以访问的最短路径执行“git clone”。例如，文件系统根目录。一旦克隆成功，您可以尝试将其移动到其他位置。如果这样做无效，则下面的技术也将不起作用，甚至不需要尝试。
- 其他原因？最好在问题中包含详细信息。如果不知道确切原因，则无法确定下面的技术是否有效。
由于存储库来自GitHub并且可以下载内容的zip，因此失败的“git clone”的结果应该是一个至少部分完整的工作树。您可以将其解压缩到失败的克隆上。结果应该是一个工作树，其内容与“master”匹配，并且您将拥有Git历史记录，正如“Clone succeeded”消息所暗示的那样。“git status”可能会报告一些更改，可能是由于符号链接被常规文件替换或不同的文件系统权限引起的，但是这似乎是您想要通过问题达到的状态。
作为另一种获取存储库历史记录的替代方法，您可以将下载的zip初始化为新的Git存储库，添加远程存储库，获取并重置它。
unzip project.zip
cd project
git init
git remote add origin url_on_github
git fetch origin
git reset origin/master
git status
git fetch 步骤将获取历史记录。如果自从你下载 zip 文件以来 master 分支上没有新提交，那么工作树的内容应该与 origin/master 最新的一致。使用 git reset origin/master 命令将使工作树与其对应的历史记录点相关联。
理想情况下 git status 命令会告诉你工作树没有任何更改。但这并不总是情况，取决于 git clone 失败的原因。你可以尝试使用 git checkout -f HEAD 命令来修复，但很可能会出现相同的错误。
\n作为行结尾，在您的本地工作树中则为\n\r。尝试从一个文件中删除\r行结尾，并查看是否有所帮助。然后从所有文件中删除。 - janos