238

我看过所有类似的问题。但是，我已经仔细检查过，肯定会发生一些奇怪的事情。

在一台服务器（带有 Git 1.8.1 的 Solaris）上，我克隆了 Git 存储库，然后将 .git 文件夹复制到我现有的实时文件中。这工作得很好，我可以跑

git status

然后

git diff [filename]

检查任何不同的文件。

在另一台服务器（带有 Git 1.7.6 的 Solaris）上，我正在做同样的事情

git diff [filename]

什么也不显示，即使文件的内容肯定不同。我还测试了添加一个新文件，提交它，然后编辑。同样的问题，git status显示文件已更改，但git diff没有显示任何内容。如果我下载更改的文件并在本地运行差异，那么我会得到差异输出。

4

16 回答 16

103

我将文件添加到索引中：

git add file_name

然后跑：

git diff --cached file_name

你可以看到git diff 这里的描述。

如果您需要撤消 git add，请参见此处：如何在提交前撤消“git add”？

于 2015-02-10T14:58:02.830 回答
101

对我来说，它与文件权限有关。在我的项目中使用 Mac/Linux 的人似乎提交了一些具有非默认权限的文件，而我的 Windows Git 客户端无法重现这些文件。

我的解决方案是告诉 Git 忽略文件权限：

git config core.fileMode false

其他见解：如何让 Git 忽略文件模式 (chmod) 更改？

于 2015-08-13T11:09:01.057 回答
74

有几个原因git status可能会显示出差异但git diff可能不会。

  • 文件的模式（权限位）已更改 - 例如，从 777 更改为 700。

  • 换行样式从 CRLF (DOS) 更改为 LF (UNIX)

找出发生了什么的最简单方法是运行git format-patch HEAD^并查看生成的补丁说明了什么。

于 2013-06-27T17:25:37.257 回答
51

我遇到了一个问题，数百个行尾被某个程序修改，并将git diff所有源文件列出为已更改。修复行尾后，git status仍将文件列为已修改。

我能够通过将所有文件添加到索引然后重置索引来解决这个问题。

git add -A
git reset

core.filemode被设置为假。

于 2016-09-27T08:13:14.833 回答
31

正如前面的回答中已经指出的那样，这种情况可能是由于行尾问题（CR/LF vs. LF）引起的。我用这个命令解决了这个问题（在 Git 版本 2.22.0 下）：

git add --renormalize .

根据手册：

       --renormalize
           Apply the "clean" process freshly to all tracked files to
           forcibly add them again to the index. This is useful after
           changing core.autocrlf configuration or the text attribute in
           order to correct files added with wrong CRLF/LF line endings.
           This option implies -u.
于 2019-07-15T14:00:26.603 回答
18

我怀疑您的 Git 安装或存储库有问题。

尝试运行：

GIT_TRACE=2 git <command>

看看有没有什么有用的。如果这没有帮助，只需使用strace看看出了什么问题：

strace git <command>
于 2013-02-20T12:44:08.287 回答
10

我有一个类似的问题：git diff会显示差异，但git diff <filename>不会。原来我设置LESS了一个包含-F( --quit-if-one-screen) 的字符串。删除该标志解决了这个问题。

于 2014-10-21T19:59:36.967 回答
9

简短的回答

跑步git add有时会有所帮助。

例子

Git 状态显示已更改的文件，而 git diff 没有显示任何内容...

> git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   package.json

no changes added to commit (use "git add" and/or "git commit -a")
> git diff
>

...运行 git add 解决了不一致问题。

> git add
> git status
On branch master
nothing to commit, working directory clean
>
于 2016-04-21T20:06:02.020 回答
6

我遇到了这个问题。我的情况类似于rcwxok 发布的LESS问题。

就我而言，我将PAGER环境变量设置为PAGER='less -RSF'.

但是，与之前的答案不同，我不想删除该-F选项，因为我明确地将它放在那里，希望防止显示差异，less如果它比一个屏幕短。

为了获得所需的结果，我没有删除-F，而是添加了-X: PAGER='less -RSFX'。这既解决了git diff问题，又防止了显示短差异less。

于 2016-11-06T10:43:53.967 回答
4

TL;博士

行尾问题：

  1. 将 autocrlf 设置更改为默认 true。即，在 Windows 上签出 Windows 风格的行尾，并在远程 Git 存储库上提交 Linux 风格的行尾： 
    git config --global core.autocrlf true
  2. 在 Windows 机器上，将存储库中的所有文件更改为 Windows 样式： 
    unix2dos **
  3. Git添加所有修改过的文件，修改后的文件会去： 
    git add .
git status

背景

  • 平台：Windows、WSL

我偶尔会遇到这个问题，git status显示我修改了文件而git diff没有显示任何内容。这很可能是行尾问题。

根本原因

我经常遇到这个问题的原因是我在 Windows 机器上工作并在WSL中与 Git 交互。在 Linux 和 Windows 设置之间切换很容易导致此行尾问题。由于操作系统中使用的行结束格式不同：

  • 视窗：\r\n
  • 操作系统/Linux：\n

常见做法

当你在你的机器上安装 Git 时，它会要求你选择行尾设置。通常，通常的做法是在远程 Git 存储库上使用（提交）Linux 样式的行尾，并在 Windows 机器上签出 Windows 样式。如果你使用默认设置，这就是 Git 为你做的。

在此处输入图像描述

这意味着，如果您的存储库中有一个 shell 脚本myScript.sh和 Bash 脚本myScript.cmd，则这些脚本都以 Linux 风格的结尾存在于您的远程 Git 存储库中，并且都以 Windows 风格的结尾存在于您的 Windows 机器上。

我曾经检查过 shell 脚本文件并使用dos2unix更改脚本行结尾以便在 WSL 中运行 shell 脚本。这就是我遇到这个问题的原因。Git 一直告诉我我对行尾的修改已更改，并询问是否提交更改。

解决方案

使用默认的行尾设置，如果您更改某些文件的行尾（如使用dos2unixor dos2unix），请删除更改。如果行尾更改已经存在并且您想摆脱它，请尝试git add它们并且更改将会消失。

于 2020-12-24T09:10:52.540 回答
3

我对您的用例的假设：

您有一个包含文件和目录的现有目录，现在想要将其转换为从其他地方克隆的 Git 存储库，而不更改当前目录中的任何数据。

真的有两种方法。

克隆 repo - mv .git- git reset --hard

此方法就是您所做的 - 将现有存储库克隆到一个空目录中，然后将该.git目录移动到目标目录中。为了没有问题地工作，这通常需要您然后运行

git reset --hard

但是，这会改变当前目录中文件的状态。您可以在目录的完整副本/rsync 上尝试此操作并研究更改内容。至少之后您应该不再看到git log和 之间的差异status。

初始化新存储库 - 指向原点

第二个不那么令人不安：cd进入您的目的地，并开始一个新的存储库

git init

然后你告诉那个新的存储库，它在其他地方有一个祖先：

git remote add origin original_git_repo_path

然后安然无恙

git fetch origin master

在不更改本地文件的情况下复制数据。现在一切都应该好了。

我总是推荐第二种方法来减少出错的可能性。

于 2013-02-19T15:27:19.883 回答
3

我刚刚遇到了类似的问题。git diff file什么也没显示，因为我将文件添加到 Git 索引中，其名称的某些部分是大写的：GeoJSONContainer.js.

之后，我将其重命名为，GeoJsonContainer.js并且更改不再被跟踪。git diff GeoJsonContainer.js什么也没显示。我不得不使用强制标志从索引中删除文件，然后再次添加文件：

git rm -f GeoJSONContainer.js
git add GeoJSONContainer.js
于 2016-08-09T09:58:24.313 回答
1

我再次偶然发现了这个问题。但这一次发生的原因不同。我已将文件复制到存储库以覆盖以前的版本。现在我可以看到文件已修改，但 diff 不返回差异。

例如，我有一个mainpage.xaml文件。在文件资源管理器中，我将一个新的mainpage.xaml文件粘贴到当前存储库中的那个文件上。我在另一台机器上完成了这项工作，然后将文件粘贴到了这里。

Git 显示已修改

该文件显示已修改，但是当我运行时git diff，它不会显示更改。

这可能是因为文件上的 fileinfo 已更改，Git 知道它实际上不是同一个文件。有趣的。

Git diff 什么也没显示

您可以看到，当我对文件运行 diff 时，它什么也不显示，只是返回提示。

于 2016-09-15T01:58:53.773 回答
1

我有以下方式描述的同样问题：如果我输入

$ git diff

Git 简单地返回提示，没有错误。

如果我输入

$ git diff <filename>

Git 简单地返回提示，没有错误。

最后，通过阅读，我注意到git diff实际上调用了mingw64\bin\diff.exe来做这项工作。

这是交易。我正在运行 Windows 并安装了另一个 Bash 实用程序，它改变了我的路径，因此它不再指向我的mingw64\bin目录。

因此，如果您键入：

git diff

它只是返回到您可能遇到此问题的提示。

实际运行的gitdiff.exe 位于您的 mingw64\bin 目录中

最后，为了解决这个问题，我实际上将我的mingw64\bin目录复制到了 Git 正在寻找它的位置。我试了一下，它仍然没有工作。

然后，我关闭了我的Git Bash窗口并再次打开它，进入了我失败的同一个存储库，现在它可以工作了。

于 2015-09-11T21:15:23.970 回答
0

git diff -a将所有文件视为文本，它对我有用。

于 2020-10-19T07:30:37.637 回答
0

我用过git svn，一个文件有这个问题。使用ls-tree文件的每个祖先，我注意到一个有 2 个子文件夹 -Submit和submit. 由于我在 Windows 上，因此无法同时检出它们，从而导致此问题。

解决方案是直接从 中删除其中一个TortoiseSVN Repo-browser，然后运行，然后git svn fetch运行git reset --hard origin/trunk​​.

于 2020-12-08T16:22:23.933 回答