我现在遇到了一个关于存储库的问题，尽管我的Git-fu通常很好，但我似乎无法解决这个问题。
当我克隆这个存储库，然后cd到存储库，git状态显示几个文件被更改。注意:我没有在任何编辑器或其他工具中打开存储库。
我试着遵循这个指南:http://help.github.com/dealing-with-lineendings/，但这对我的问题一点帮助都没有。
我试过git checkout。很多次，但似乎什么也没做。
我使用的是Mac，存储库本身没有子模块。
Mac上的文件系统是“Journaled HFS+”文件系统，不区分大小写。这些文件只有一行，每个文件大约79 KB(是的，您没有听错)，因此查看git diff并没有特别有用。我听说过git的全局核心配置。trustctime false，这可能有帮助，当我回到存储库的计算机上时，我会尝试。
我用事实改变了文件系统的细节!我尝试了git配置——全局核心。Trustctime假把戏，效果不太好。
当前回答
我也遇到了同样的问题。在我的例子中，我克隆了存储库，一些文件立即丢失了。
这是由于文件的路径和文件名对Windows来说太长造成的。要解决该问题，请将存储库克隆到尽可能靠近硬盘驱动器根的位置，以减少文件路径的长度。例如，将其克隆到C:\A\GitRepo，而不是C:\ users Documents\yyy\Desktop\GitRepo。
其他回答
编辑名为.git/config的文件:
sudo gedit .git/config
Or:
sudo vim .git/config
内容
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "origin"]
url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "productapproval"]
remote = origin
merge = refs/heads/productapproval
将filemode=true更改为filemode= false。
我猜你用的是Windows。你链接到的GitHub页面的细节是相反的。问题是CR + LF行结束已经提交到存储库，因为您有核心。如果将selflf设置为true或input, Git希望将行结束符转换为LF，因此Git状态显示每个文件都被更改了。
如果这是一个您只想访问但不涉及的存储库，则可以运行以下命令来仅仅隐藏问题，而不实际解决问题。
git config core.autocrlf false
如果这是一个您将积极参与并可以提交更改的存储库。您可能希望通过提交将存储库中的所有行结束符更改为使用LF而不是CR + LF来修复这个问题，然后采取措施防止将来再次发生这种情况。
下面的代码直接取自gitattributes手册页，应该在一个干净的工作目录中执行。
echo "* text=auto" >>.gitattributes
rm .git/index # Remove the index to force Git to
git reset # re-scan the working directory.
git status # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"
如果在git状态中出现了任何不应该被规范化的文件，在运行git add -u之前取消设置它们的文本属性。
manual.pdf -text
相反，Git不检测的文本文件可以手动启用规范化。
weirdchars.txt text
这个问题也可能由不同的文件权限引起，就像我的情况一样:
新克隆的存储库(Windows, Cygwin):
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
裸远程存储库(Linux):
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
我明白了。所有其他的开发人员都使用Ubuntu(我想)，因此都有区分大小写的文件系统。然而，我没有(因为我用的是Mac)。实际上，当我使用git ls-tree HEAD <path>查看它们时，所有文件都有小写双胞胎。
我会让他们中的一个去解决的。
在克隆了一个存储库之后，我在Mac上也遇到了同样的问题。它假定所有文件都已更改。
运行git config——global core后。输入时，它仍然将所有文件标记为已更改。在寻找修复后，我在主目录中遇到了.gitattributes文件，其中包含以下内容。
* text=auto
我把它注释掉了，从此以后任何其他克隆的存储库都可以正常工作。
