249

目前我的存储库有问题，虽然我的 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效果不佳的技巧。

4

19 回答 19

148

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

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

* text=auto

我将其注释掉，从现在开始，任何其他克隆的存储库都可以正常工作。

于 2012-04-28T12:27:09.960 回答
93

我得到了它。所有其他开发人员都在 Ubuntu 上（我认为），因此具有区分大小写的文件系统。但是，我不这样做（因为我在 Mac 上）。事实上，当我使用git ls-tree HEAD <path>.

我会找其中一个来解决。

于 2011-02-16T21:35:48.530 回答
87 
git config core.fileMode false

在我的情况下解决了这个问题

https://git-scm.com/docs/git-config

TL;博士;

核心文件模式

如果为 false，则忽略索引和工作树之间的可执行位差异；在 FAT 等损坏的文件系统上很有用。请参阅 git-update-index(1)。

默认值为 true，但 git-clone(1) 或 git-init(1) 将在创建存储库时探测并将 core.fileMode 设置为 false（如果合适）。

于 2015-07-02T14:24:58.333 回答
58

我假设您使用的是 Windows。您链接到的那个 GitHub 页面的详细信息倒数。问题是 CR + LF 行尾已经提交到存储库，并且因为您将core.autocrlf设置为true或input，Git 想要将行尾转换为 LF，因此git status表明每个文件都已更改。

如果这是您只想访问但不参与的存储库，则可以运行以下命令仅隐藏问题而不实际解决问题。

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 status请在运行前取消设置它们的文本属性git add -u。

manual.pdf      -text

相反，Git 未检测到的文本文件可以手动启用规范化。

weirdchars.txt  text
于 2011-02-15T21:06:34.917 回答
42

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

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

# Write both the index and working directory from git's database.
git reset --hard
于 2015-04-17T07:50:27.237 回答
16

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

* text=auto

此行位于文件顶部附近。我们只需要通过在前面添加 # 来注释掉该行。之后，事情按预期进行。

于 2013-10-25T14:48:38.303 回答
12

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

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

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

裸远程存储库（Linux）：

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑
于 2014-05-14T12:44:52.490 回答
5

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

所以，.gitattributes有一个* text=auto设置，这会导致这个问题。

就我而言，GitHub 主分支上的文件有\r\n结尾。我已拨出存储库上的设置以签入\n结尾。我不知道 Git 检查了什么。它应该以原生结尾签出到我的 Linux 盒子 ( \n) 上，但我猜它签出了带有\r\n结尾的文件。Git 抱怨是因为它看到了\r\n存储库中已签出的结尾，并警告我它将签入\n设置。因此文件是“要修改的”。

这就是我目前的理解。

于 2014-02-27T18:36:21.410 回答
4

对我来说同样的问题。我可以在远程 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
于 2018-11-22T08:58:51.897 回答
3

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

geoip.dat 和 GeoIP.dat

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

于 2013-10-21T08:17:44.387 回答
1

我也遇到了同样的问题。就我而言，我克隆了存储库，一些文件立即丢失了。

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

于 2013-12-13T08:48:26.387 回答
1

编辑名为.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.

于 2017-10-24T07:02:35.307 回答
1

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

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

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

但是在文件上设置这个属性也改变了文件，因此它出现在 Git 更改集中而没有任何恢复它的方式。

你可以通过运行来检查你是否有同样的问题$ xattr file.app。

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

于 2018-11-21T08:13:55.337 回答
1

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

于 2021-04-22T14:33:35.797 回答
0

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

于 2015-04-22T08:26:29.463 回答
0

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

*.psd binary
于 2015-09-10T21:33:32.807 回答
0

我试图做一个交互式变基，但它声称有一些修改过的文件，所以它不会让我现在这样做。我尽一切努力回到一个干净的存储库，但没有任何效果。其他答案都没有帮助。但这终于奏效了……

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

繁荣！清洁存储库。问题解决了。然后我只需要放弃最后一次提交rebase -i，最后一切都变得干净了。奇怪！

于 2018-08-10T11:09:32.510 回答
0

万一它对其他人有帮助，这个问题可能还有另一个原因：不同版本的 Git。我在 Ubuntu 18.04 (Bionic Beaver) 机器上使用了默认安装的 Git 版本，一切正常，但是当尝试在 Ubuntu 16.04 上使用 Git 克隆存储库时，一些文件显示为已修改。

这里的其他答案都没有解决我的问题，但是升级 Git 的版本以在两个系统上匹配确实解决了这个问题。

于 2019-04-08T13:57:01.833 回答
0

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

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

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

解决方案是重命名foo.py为与原始文件完全不同的文件名。进行该更改后，该问题随着存储库的新克隆而消失。

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

于 2020-10-21T15:55:43.633 回答