Question

我现在遇到了一个存储库问题，虽然我的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诀窍，效果不佳。

Answer 1

克隆存储库后我在Mac上遇到了同样的问题。它会假设所有文件都已更改。

运行git config --global core.autocrlf input后，它仍然将所有文件标记为已更改。在寻找修复后，我遇到了主目录中的.gitattributes文件，其中包含以下内容。

* text=auto

我评论过它，从现在起任何其他克隆的存储库都运行良好。

Answer 2

我明白了。所有其他开发人员都在Ubuntu（我认为），因此具有区分大小写的文件系统。但是，我没有（因为我在Mac上）。实际上，当我使用git ls-tree HEAD <path>查看它们时，所有文件都有小写双胞胎。

我会让其中一个人解决它。

Answer 3

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。

Answer 4

我假设您使用的是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

Answer 5

请运行以下命令。这可能会解决问题。

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Answer 6

在Visual Studio中，如果您使用的是Git，则可以自动生成.gitignore和.gitattributes文件。自动生成的.getattributes文件包含以下行：

* text=auto

此行靠近文件顶部。我们只需要在前面添加一个＃来评论该行。在这之后，事情按预期运作。

Answer 7

问题可能还来自不同的文件权限，就像我的情况一样：

新鲜的克隆存储库（Windows，Cygwin）：

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

裸露的远程存储库（Linux）：

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Answer 8

我想添加更多针对“为什么”这种情况发生的答案，因为对于如何修复它已经有了一个很好的答案。

因此，.gitattributes设置了* text=auto，导致此问题。

就我而言，GitHub主分支上的文件有\r\n个结尾。我已拨打存储库中的设置以使用\n结尾签到。我不知道Git检查了什么。它应该使用原生结尾检查我的Linux框（\n），但我想它检查了\r\n结尾的文件。 Git会抱怨，因为它会看到存储库中已检出的\r\n结尾，并警告我它将检入\n设置。因此文件“被修改”。

这是我现在的理解。

Answer 9

我遇到了同样的问题。还有一台Mac。查看Linux机器上的存储库，我注意到我有两个文件：

geoip.dat和GeoIP.dat

我在Linux机器上删除了已弃用的程序，并将存储库再次克隆到Mac。当有重复项时，我无法从我的存储库副本中提取，提交，存储或提取。

Answer 10

对我来说同样的问题。我可以在远程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

Answer 11

我的问题是在我的 MacBook 上，我的 Mac 没有按大小写进行跟踪。我创建了一个 APFS 区分大小写的“工作区”分区。之后，我不再收到状态错误。

Answer 12

对于新版本的macOS，这可能是由操作系统的安全功能引起的。

在我正在处理的存储库中，有一个二进制文件，文件类型为* .app。

这只是一些序列化的数据，但是macOS将所有* .app文件都视为一个应用程序，并且由于该文件不是由用户下载的，因此系统认为它是不安全的，并添加了com.apple.quarantine文件属性，以确保该文件无法执行。

但是在文件上设置此属性也会更改文件，因此它显示在Git更改集中，而没有任何还原方法。

您可以通过运行$ xattr file.app来检查是否存在相同的问题。

该解决方案非常简单，只要您不必使用该文件即可。只需将*.app binary添加到您的.gitattributes中即可。

Answer 13

编辑名为.git/config的文件：

sudo gedit .git/config

或者：

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。

Answer 14

我也遇到了同样的问题。在我的情况下，我克隆了存储库，一些文件立即丢失。

这是由文件的路径引起的，而文件名对于Windows来说太长了。要解决此问题，请将存储库克隆到尽可能靠近硬盘驱动器根目录的位置，以减少文件路径的长度。例如，将其克隆为C:\A\GitRepo而不是C:\Users Documents\yyy\Desktop\GitRepo。

Answer 15

我正在尝试进行交互式变基，但它声称存在一些已修改的文件，因此现在不允许我这样做。我尝试了一切以返回到干净的存储库，但没有任何效果。其他答案均无济于事。但这终于奏效了...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

轰！清理存储库。问题解决了。然后，当我做rebase -i时，我只需要放弃最后的提交，最后一切都变得干净了。奇怪！

Answer 16

我发现Git正在处理我的文件（本例中为.psd）作为文本。在.gitattributes中将其设置为二进制类型解决了它。

*.psd binary

Answer 17

我将本地存储库复制到另一个文件夹，并显示了一堆修改过的文件。我的解决方法是：我存储了已修改的文件并删除了存储。存储库变得干净了。

Answer 18

Just in case it helps someone else, there can be another cause for this problem: differing versions of Git. I was using the default installed version of Git on a Ubuntu 18.04 (Bionic Beaver) box and everything was working fine, but when trying to clone the repository using Git on Ubuntu 16.04, some files were showing up as modified.

None of the other answers here fixed my problem, but upgrading the versions of Git to match on both systems did fix the problem.

Answer 19

我在MacOS上遇到了相关问题。

也就是说，有些人可能没有意识到，尽管看起来MacOS的文件系统区分大小写，但事实并非如此。它将存储大小写混合的文件名，但例如，将Foo.py和foo.py视为同一文件。

某位同事通过将foo.py制作为Foo.py作为开发框架的一部分来创建了这样的场景。（即，不仅要强制执行PEP8模块文件命名约定，而且要从原始文件中大大重构其内容，以便我们希望并行执行此类工作）。当我撤消这些更改时，MacOS将foo.py的所有修改覆盖到Foo.py中，这导致git认为我进行了本地更改，而我没有进行本地更改。进行新克隆时，git立即声称Foo.py有了显着变化，即使它是新克隆。

解决方案是将foo.py重命名为一个完全不同的文件名，该文件名与原始文件完全没有冲突。进行更改后，问题又有了新的存储库克隆。

（有一个系统配置标志可以打开MacOS的区分大小写的行为，但建议将其保留为默认设置，因为切换该行为可能会破坏预期不区分大小写的行为。）

在Git克隆之后直接显示为已修改的文件

19 个答案:

目录