执行git add .后显示无内容可提交是什么原因？

出现该现象的核心逻辑是：Git执行git status时为了提升运行效率，默认不会逐字节读取文件计算内容哈希，仅先比对文件的元数据（修改时间、文件大小、inode编号、权限位等），只要元数据和本地索引记录不一致，就会先将文件标记为已修改；而执行git add .时，Git会实际读取文件全量内容、按配置规则做格式转换后计算哈希值，如果最终计算出的哈希和当前HEAD分支中对应文件的哈希完全一致，Git不会生成新的暂存记录，反而会更新本地索引中存储的文件元数据，后续再执行git status就会显示工作目录干净。

常见的触发场景有三类：

• 复制覆盖的同名文件实际内容和仓库内原有文件完全一致，仅文件修改时间、创建时间等元数据发生了变化。
• Git换行符自动转换规则生效：如果本地开启了core.autocrlf配置，或者仓库内新增了.gitattributes文件定义了换行符转换规则，复制到本地的文件换行符（比如Windows的CRLF换行）会在git add阶段被自动转换为仓库存储的标准格式（通常是LF换行），转换后的内容和仓库原有文件完全一致。
• 文件权限差异被忽略：如果本地Git配置了core.filemode=false，复制文件时带来的权限位变化（比如普通文件变为可执行文件、反之亦然）会在git add阶段被直接忽略，不会被识别为有效变更。

上周相同流程可正常运行、本次失效，通常是因为本地Git客户端配置被更新、仓库新增了.gitattributes规则、或是本次复制的源文件本身内容和当前仓库HEAD版本无实质差异导致的。

• 任选一个第一次执行git status时显示为已修改的文件，执行git diff <文件路径>，如果命令无任何输出，即可确认文件经过Git规则处理后和仓库版本无实质内容差异。
• 执行git config core.autocrlf查看换行符配置，若返回值为true或input，可临时执行git config core.autocrlf false关闭自动转换，重复操作验证是否是换行符转换导致的问题。
• 执行git config core.filemode查看权限识别配置，若复制文件时修改了文件可执行权限，该配置为false时会直接忽略权限类变更。
• 直接比对复制的源文件和仓库内对应文件的原始内容，确认是否存在实质修改，排除误操作复制了同版本文件的情况。

内容的提问来源于stack exchange，提问作者Jay