我现在遇到了一个存储库问题，虽然我的Git-fu通常很好，但我似乎无法解决这个问题。
当我克隆这个存储库，然后cd进入存储库时，git status会显示几个已更改的文件。注意：我没有在任何编辑器或任何东西中打开存储库。
我尝试按照本指南：http://help.github.com/dealing-with-lineendings/，但这对我的问题没有任何帮助。
我曾多次尝试过git checkout -- .，但似乎没有做任何事情。
我在Mac上，并且存储库本身没有子模块。
文件系统是Mac上的“Journaled HFS +”文件系统，不区分大小写。这些文件是一行的，每个大约79 KB（是的，你听到了），所以看看git diff并不是特别有用。我听说过做git config --global core.trustctime false可能会有所帮助，当我回到带有存储库的计算机时，我会尝试。
我用事实改变了文件系统的细节！我尝试了git config --global core.trustctime false技巧，但效果不佳。
克隆存储库后，我在Mac上遇到了同样的问题。它会假设所有文件都已更改。
运行git config --global core.autocrlf input后，它仍然将所有文件标记为已更改。在寻找修复后，我遇到了主目录中的.gitattributes文件，其中包含以下内容。
* text=auto
我评论了它，从现在开始任何其他克隆的存储库工作正常。
对我来说同样的问题。我可以看到几个具有相同名称的图像，如远程Git存储库中的“textField.png”和“textfield.png”，但不在我的本地存储库中。我只能看到项目代码中没有使用的“textField.png”。
事实证明，我的大多数同事使用ext4文件系统在Ubuntu上，而我在使用APFS的Mac上。
感谢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
要么
# Global Git configuration
git config --global core.ignorecase = true
我也遇到了同样的问题。在我的情况下，我克隆了存储库，一些文件立即丢失。
这是由文件的路径和Windows的文件名太长造成的。要解决此问题，请将存储库克隆到尽可能靠近硬盘驱动器根目录的位置，以减少文件路径的长度。例如，将其克隆到C:\A\GitRepo而不是C:\Users Documents\yyy\Desktop\GitRepo。
编辑名为.git/config的文件：
sudo gedit .git/config
要么：
sudo vim .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "origin"]
url = [email protected]: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。
对于新版本的macOS，这可能是由操作系统的安全功能引起的。
在我正在处理的存储库中，有一个二进制文件，其中包含* .app作为文件类型。
它只是一些序列化数据，但macOS将所有* .app文件视为一个应用程序，并且由于该文件未被用户下载，系统认为它不安全并添加了com.apple.quarantine文件属性，以确保文件无法执行。
但是在文件上设置此属性也是在更改文件，因此它出现在Git更改集中而没有任何恢复它的方法。
您可以通过运行$ xattr file.app来检查是否存在同样的问题。
解决方案非常简单，只要您不必使用该文件即可。只需将*.app binary添加到您的.gitattributes。
我将本地存储库复制到另一个文件夹，并显示了一堆修改过的文件。我的解决方法是：我隐藏了修改过的文件并删除了存储。存储库变得干净。
我发现Git正在处理我的文件（在这种情况下为.psd）作为文本。在.gitattributes中将其设置为二进制类型解决了它。
*.psd binary
我试图做一个交互式的rebase，但它声称有一些修改过的文件，所以它不会让我现在就这样做。我尝试了所有东西以回到干净的存储库，但没有任何效果。其他答案都没有帮助。但这终于奏效了......
git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'
繁荣！清理存储库。问题解决了。然后，当我做我的rebase -i时，我不得不放弃最后一次提交，最后一切都很干净了。离奇！
为了防止其他人，可能会有另一个原因造成这个问题：不同版本的Git。我在Ubuntu 18.04（Bionic Beaver）盒子上使用默认安装的Git版本，一切正常，但是当尝试在Ubuntu 16.04上使用Git克隆存储库时，一些文件显示为已修改。
这里没有其他答案解决我的问题，但升级Git版本以匹配两个系统确实解决了问题。
我知道了。所有其他开发人员都在Ubuntu（我认为），因此具有区分大小写的文件系统。但是，我没有（因为我在Mac上）。实际上，当我使用git ls-tree HEAD <path>查看它们时，所有文件都有小写双胞胎。
我会让他们中的一个来解决它。
git config core.fileMode false
在我的情况下解决了这个问题
https://git-scm.com/docs/git-config
TL; DR;
core.fileMode
如果为false，则忽略索引和工作树之间的可执行位差异;对像FAT这样的破碎文件系统很有用。请参阅git-update-index（1）。
默认值为true，但git-clone（1）或git-init（1）将在创建存储库时探测并设置core.fileMode false。
我假设您使用的是Windows。您链接到的GitHub页面具有向后的详细信息。问题是CR + LF行结尾已经提交到存储库，因为你将core.autocrlf设置为true或者输入，Git想要将行结尾转换为LF，所以git status显示每个文件都被更改。
如果这是一个您只想访问但不涉及的存储库，则可以运行以下命令来隐藏问题而不实际解决问题。
git config core.autocrlf false
如果这是您将积极参与的存储库，并且可以提交更改。您可能希望通过进行更改存储库中所有行结尾的提交来使用LF而不是CR + LF来解决问题，然后采取措施防止将来再次发生。
以下内容直接来自gitattributes man page，应该从干净的工作目录中执行。
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 status中，请在运行git add -u之前取消设置其文本属性。
manual.pdf -text
相反，Git未检测到的文本文件可以手动启用规范化。
weirdchars.txt text
请运行以下命令。这可能会解决问题。
# Remove everything from the index.
git rm --cached -r .
# Write both the index and working directory from git's database.
git reset --hard
在Visual Studio中，如果您使用的是Git，则可以自动生成.gitignore和.gitattributes文件。自动生成的.getattributes文件包含以下行：
* text=auto
此行靠近文件的顶部。我们只需要在前面添加一个＃来评论该行。在这之后，事情按预期运作。
问题也可能来自不同的文件权限，我的情况也是如此：
新鲜的克隆存储库（Windows，Cygwin）：
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
裸露的远程存储库（Linux）：
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
我想添加更多针对“为什么”这样的答案，因为已经有一个很好的答案如何解决它。
所以，.gitattributes有一个* text=auto设置，这导致了这个问题。
就我而言，GitHub主分支上的文件有\r\n结尾。我已经拨打了存储库中的设置以使用\n结尾办理登机手续。我不知道Git检查了什么。它应该检查我的Linux盒子（\n）上的原生结尾，但我想它用\r\n结尾检查了文件。 Git抱怨是因为它看到了存储库中已检出的\r\n结尾并警告我它将检查\n设置。因此文件“被修改”。
那是我现在的理解。
我有同样的问题。还有一台Mac。查看Linux机器上的存储库，我注意到我有两个文件：
geoip.dat和GeoIP.dat
我在Linux机器上删除了已弃用的程序，并再次将存储库克隆到Mac。当有重复时，我无法从我的存储库副本中提取，提交，存储或提取。