我现在遇到了一个关于存储库的问题，尽管我的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。你链接到的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
我明白了。所有其他的开发人员都使用Ubuntu(我想)，因此都有区分大小写的文件系统。然而，我没有(因为我用的是Mac)。实际上，当我使用git ls-tree HEAD <path>查看它们时，所有文件都有小写双胞胎。
我会让他们中的一个去解决的。
在克隆了一个存储库之后，我在Mac上也遇到了同样的问题。它假定所有文件都已更改。
运行git config——global core后。输入时，它仍然将所有文件标记为已更改。在寻找修复后，我在主目录中遇到了.gitattributes文件，其中包含以下内容。
* text=auto
我把它注释掉了，从此以后任何其他克隆的存储库都可以正常工作。
我也有同样的问题。在Mac上也是如此。在Linux机器上查看存储库，我注意到我有两个文件:
geoip.dat和geoip.dat
我在Linux机器上删除了废弃的版本，并将存储库再次克隆到Mac上。当存在副本时，我无法提取、提交、保存或从我的存储库副本中提取。
在Visual Studio中，如果你正在使用Git，你可以自动生成.gitignore和.gitattributes文件。自动生成的.getattributes文件有以下一行:
* text=auto
这一行位于文件的顶部附近。我们只需要在该行前面添加#来注释该行。在此之后，事情按预期运行。
我也遇到了同样的问题。在我的例子中，我克隆了存储库，一些文件立即丢失了。
这是由于文件的路径和文件名对Windows来说太长造成的。要解决该问题，请将存储库克隆到尽可能靠近硬盘驱动器根的位置，以减少文件路径的长度。例如，将其克隆到C:\A\GitRepo，而不是C:\ users Documents\yyy\Desktop\GitRepo。
我想添加一个关于“为什么”会发生这种情况的更直接的答案，因为关于如何解决它已经有了一个很好的答案。
因此，.gitattributes有一个* text=auto设置，这导致了这个问题。
在我的例子中，GitHub主分支上的文件有\r\n个结尾。我已经拨出了存储库上的设置，以使用\n个结尾签入。但我不知道Git会检查出什么。它应该在我的Linux盒子(\n)上检出本机结尾，但我猜它检出了带有\r\n结尾的文件。Git抱怨是因为它看到了存储库中检出的\r\n个结尾，并警告我它将检入\n个设置。因此文件是“待修改”的。
这是我目前的理解。
这个问题也可能由不同的文件权限引起，就像我的情况一样:
新克隆的存储库(Windows, Cygwin):
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
裸远程存储库(Linux):
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
请执行以下命令。这也许能解决问题。
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
git config core.fileMode false
解决了我的这个问题
https://git-scm.com/docs/git-config
TL; diana;
core.fileMode
如果为false，则忽略索引和工作树之间的可执行位差异;对FAT等损坏的文件系统很有用。看到git-update-index(1)。
默认为true，除非git-clone(1)或git-init(1)将探测和设置core。在创建存储库时，fileMode为false(如果合适)。
编辑名为.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。
我试图做一个交互式的重基，但它声称有一些修改过的文件，所以它不让我现在做。我尝试了所有方法来恢复一个干净的存储库，但都没用。其他答案都没用。但这最终奏效了……
git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'
繁荣!干净的存储库。问题解决了。然后，当我执行rebase -i时，我不得不放弃最后一次提交，最后一切都重新干净了。奇怪的!
对于新版本的macOS，这可能是由操作系统的安全特性引起的。
在我工作的存储库中，有一个二进制文件带有*。App作为文件类型。
这只是一些序列化的数据，但macOS处理所有*。App文件作为一个应用程序，由于该文件没有被用户下载，系统认为它是不安全的，并添加了com.apple.quarantine文件属性，以确保该文件不能执行。
但是在文件上设置这个属性也会改变文件，因此它会显示在Git更改集中，而没有任何恢复它的方法。
您可以通过运行$ xattr file.app来检查是否有相同的问题。
解决方案非常简单，只要您不需要使用该文件。只要加上*。应用二进制到你的.gitattributes。
我也一样。我可以在远程Git存储库中看到几个名称相同的图像，比如“textField.png”和“textField.png”，但在本地存储库中看不到。我只能看到“textField.png”在项目的代码中没有使用。
我的大多数同事在Ubuntu上使用ext4文件系统，而我在Mac上使用APFS。
多亏了Sam Elliott的回答，解决方法非常简单。首先，我让Ubuntu的一位同事删除了带有大写字母的冗余文件版本，然后提交并远程推送。
然后我运行以下程序:
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
最后，我们决定每个开发人员都应该改变他的Git配置，以防止这种情况再次发生:
# Local Git configuration
git config core.ignorecase true
or
# Global Git configuration
git config --global core.ignorecase true
为了防止它帮助其他人，这个问题可能还有另一个原因:不同版本的Git。我在Ubuntu 18.04 (Bionic Beaver)的机器上使用默认安装的Git版本，一切工作正常，但在Ubuntu 16.04上尝试使用Git克隆存储库时，一些文件显示为已修改。
这里的其他答案都没有解决我的问题，但是升级Git版本以匹配两个系统确实解决了这个问题。
我在MacOS上遇到了相关问题。
也就是说，有些人可能没有意识到，虽然MacOS的文件系统看起来是区分大小写的，但事实并非如此。它将存储混合的案例文件名，但是，例如，考虑Foo.py和Foo.py是同一个文件。
A colleague had created just such a scenario by making a foo.py from a Foo.py as part of a development scaffolding. (I.e., not only enforcing PEP8 module file naming conventions, but refactoring the contents significantly from the original such that we wanted to do that kind of work in parallel). When I pulled those changes, MacOS overwrote all the modifications from foo.py into Foo.py, which caused git to think I had made local changes, when I hadn't. When doing a fresh clone, git immediately claimed that Foo.py had significant changes even though it was a fresh clone.
解决方案是将foo.py重命名为一个完全不同的文件名，并且不与原始文件名冲突。在做出更改后，这个问题随着存储库的新克隆而消失了。
(有一个系统配置标志可以在MacOS中打开区分大小写的行为，但建议将其保留在默认设置中，因为切换该行为可能会破坏期望区分大小写的行为。)
