执行git add .命令时出现LF转CRLF行尾符警告的解决方法咨询

该警告的触发逻辑为：Git的行尾自动转换规则检测到文件实际行尾格式与配置规则的转换预期不匹配，示例中提到的frontend/node_modules/@babel/preset-env/lib/filter-items.js只是触发规则检测的具体文件，并非文件本身存在损坏。

标准解决操作步骤 #

1. 匹配项目场景设置全局行尾转换规则 #

根据项目跨环境协作的实际场景，设置对应的core.autocrlf配置，从基础逻辑上匹配转换预期：

• 跨Windows、Linux、macOS多环境协作的项目，执行git config --global core.autocrlf true：提交入库的文件统一标准化为LF行尾，Windows环境本地检出工作区文件时自动转换为CRLF，匹配Windows系统的行尾默认规则。
• 纯Linux、macOS环境的项目，执行git config --global core.autocrlf input：提交时自动将行尾规整为LF，本地工作区保留原始LF格式不做额外转换。
• 仅在Windows环境单人维护、无跨系统同步需求的项目，可执行git config --global core.autocrlf false：完全保留文件原始行尾格式，不执行自动转换逻辑。

2. 批量规整仓库现有文件的行尾一致性 #

仅修改全局配置无法解决仓库历史中混合存在LF、CRLF行尾文件的问题，会导致警告反复触发，需执行一次批量规范化操作：

• 先确保当前工作区无未提交的本地改动，执行git add --renormalize .，该命令会按照已设置的行尾规则，重新遍历匹配工作区所有被追踪文件的行尾格式，将不符合规则的内容一次性修正，完成后提交修正结果即可。
• 检查仓库的追踪范围，正常项目中node_modules依赖目录不应被纳入Git追踪范围，这类来自依赖包路径的行尾警告，多数是因为未配置忽略规则导致：在项目根目录的.gitignore文件中新增node_modules/条目，将依赖目录排除在追踪范围外，后续来自依赖目录的同类行尾警告会直接消失。

3. 配置项目级强制规则，从根源避免警告复发 #

个人本地的全局配置无法约束团队其他成员的设置差异，容易再次出现行尾不匹配的警告，需在项目根目录新增.gitattributes文件，设置优先级更高的项目级行尾规则，该规则对所有拉取项目的成员自动生效：

* text=auto eol=lf
*.png binary
*.jpg binary
*.zip binary

规则说明：所有文本类文件统一强制使用LF行尾入库，二进制类文件标记为非文本属性，不执行行尾转换，避免损坏文件内容。

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