Git索引与工作区文件哈希对比结果不一致的原因排查

我来帮你分析下为啥会出现这种哈希不一致的情况，结合你用Git命令对比工作区和索引文件的场景，主要有这几个常见原因：

1. 工作区文件未暂存，与索引状态不一致 #

git hash-object是直接计算当前工作区文件内容的哈希值，而git ls-files -s读取的是Git索引中已经暂存的文件哈希。如果你的工作区文件已经做了修改，但还没执行git add把修改同步到索引，那两者的哈希必然会不一样。比如你修改了locationX/fileA但没暂存，git hash-object拿到的是修改后的内容哈希，git ls-files -s还是旧的暂存版本哈希，自然对不上。

2. 换行符自动转换导致的哈希差异 #

Git有core.autocrlf配置项，会根据操作系统自动转换文件换行符（比如Windows的CRLF和Linux的LF）。工作区的文件可能是CRLF格式，但Git索引中存储的是标准化后的LF格式，这时候两者计算出的哈希就会不同。你可以用git config --get core.autocrlf查看当前配置，如果是true或input，就大概率是这个问题。

你可以试试用git hash-object --no-filters命令跳过Git的换行符转换，直接计算工作区文件原始内容的哈希，再和git ls-files -s的结果对比，如果这时候一致，就能确认是换行符转换导致的差异。

3. Git过滤器（Smudge/Clean）的影响 #

如果你的仓库配置了Git过滤器（比如用Git LFS管理大文件，或者自定义了内容处理过滤器），索引中存储的是经过过滤器处理后的内容哈希，而工作区的文件是原始内容，两者哈希自然不一致。比如Git LFS会把大文件替换成指针文件存储在索引里，工作区则是实际的大文件，这时候哈希肯定完全不同。

你可以用git config --list | grep filter查看是否配置了相关过滤器。

4. 命令执行时的路径错误 #

你在PowerShell中执行命令时，要确保路径指向的是同一个文件。Git命令在仓库内执行时，相对路径是基于仓库根目录的，如果你混用了绝对路径和相对路径，可能不小心对比了不同文件的哈希（比如误把locationX/fileA的工作区文件和locationY/fileA的索引文件做对比）。

建议你切换到仓库根目录后，用相对路径执行命令：

# 对比locationX/fileA的索引哈希和工作区哈希
git ls-files -s locationX/fileA
git hash-object locationX/fileA

针对你场景的额外排查建议 #

你需要确保两个路径下的fileA在工作区和已提交版本都一致，除了上面的点，还可以：

• 检查已提交版本的两个文件是否真的一致：用git hash-object HEAD:locationX/fileA和git hash-object HEAD:locationY/fileA对比哈希，或者直接用git diff HEAD:locationX/fileA HEAD:locationY/fileA查看内容差异。
• 对比工作区两个文件的内容：直接用PowerShell的Compare-Object命令，或者Get-Content读取后对比，先确认工作区的两个文件本身是否一致。

备注：内容来源于stack exchange，提问作者Justin Briggs