对于使用v2.16或更高版本的用户，您可以简单地使用：

git add --renormalize .  # Update index with renormalized files
git status               # Show the files that will be normalized
git commit -m "Introduce end-of-line normalization"

这些方向直接来自gitattributes。对于旧版本，文档（v2.12之前）提供了不同的答案：

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"

编辑完.gitattributes后执行此序列。

更新

似乎有些用户在使用上述说明时遇到了麻烦。gitattributes的更新文档（2.12到2.14）显示了一组新的说明（在编辑. gitattributes文件之后）：

git read-tree --empty   # Clean index, force re-scan of working directory
git add .
git status        # Show files that will be normalized
git commit -m "Introduce end-of-line normalization"

感谢@vossad01指出这一点。
此外，无论使用哪种解决方案，工作副本中的文件仍保留其旧的行尾。如果你想更新它们，请确保你的工作树是干净的，并使用：

git rm --cached -r .
git reset --hard

现在，工作树中的行尾将是正确的。

使用Git客户端2.16及更高版本，现在有一种更简单的方法来做到这一点。只需用途：

git add --renormalize .

注意：最好是在干净的工作空间中进行此操作。有关详细信息，请参见：

• https://git-scm.com/docs/gitattributes#_end_of_line_conversion
• https://help.github.com/en/github/using-git/configuring-git-to-handle-line-endings#refreshing-a-repository-after-changing-line-endings

可选方式（仅命令不同）

确保您在存储库中没有任何挂起的更改：

$ git status
$ git stash

修改.gitattributes，以使CRLF解释发生变化：

$ echo "*.txt  text" >>.gitattributes
$ git commit -m "Made .txt files a subject to CRLF normalization." -- .gitattributes

从索引中删除数据并刷新工作目录：

$ git rm --cached -r .
$ git reset --hard

查看Git建议的CRLF修复：

$ git ls-files --eol
$ git status
$ git diff

同意Git的决定：

$ git add -u
$ git commit -m "Normalized CRLF for .txt files"

重新加载更改，就像完成了干净克隆一样：

$ git rm --cached -r .
$ git reset --hard

.gitattributes设置只会影响新的提交。如果这个仓库没有发布历史记录（没有其他人依赖它），你可能想浏览整个历史记录。在Unix/Linux中，你可以使用dos2unix(1)和find(1)来修复所有文件，使用filter-branch的历史重写（参见git手册中的discussion），你甚至可以清理项目的完整历史。
使用时要格外小心，在一个新鲜的克隆。与任何可能有克隆人的人联系，并建议他们你想做什么。

.gitattributes中的 * text=auto选项会使Git存储库处于“非法状态”，如果它包含带有CRLF（Windows）行结尾的文件，而这些文件现在被标记为文本（参见https://marc.info/?l=git&m=154484903528621&w=2）。标准的renormalize选项不能正确使用LFS过滤器，因此其他答案中的说明或例如https://help.github.com/en/articles/dealing-with-line-endings中的说明不能正确工作。相反，这些步骤对我们有效：
情况：

• 在Windows上
• Git存储库包含同时以CR和CRLF行结尾的文件
• 在.gitattributes中添加了 * text=auto（因此不依赖于用户在Windows上设置了core.crlf=auto）

1.还将LFS跟踪文件的-crlf更改为-text，不确定是否需要。
1.从有行尾问题的分支创建一个新分支（假设那里没有未提交的更改）：git checkout -B feature/doing-stuff-fix-eol
1.从.gitattributes中删除LFS过滤器（将所有'filter=lfs diff=lfs merge=lfs '替换为nothing）
1.提交并推送：git commit -a -m“Disable LFS filters for EOL fix”
1.移动到非git文件夹
1.全局卸载LFS：git lfs uninstall
1.创建新的存储库克隆：git clone -B feature/doing-stuff-fix-eol [remote repository url] fix-eol
1.规格化行尾：git add --renormalize .（注意重新规范化所有文件的点）
1.仅检查规范化的正确文件。它不应该包括通常由LFS处理的文件！
1.提交并推送（保存哈希）：git commit -m“修复行结尾”
1.移动到非git文件夹
1.全局安装LFS：git lfs install
1.转到原始存储库克隆并拉取
1.查看您的原始分支：git checkout feature/doing-stuff

1. Cherry选择eol修复提交并推送：git cherry-pick [hash]
   1.删除eol分支并推送
   1.删除EOL存储库克隆（如果需要修复更多分支，则可以保留）

我不得不用这个标志-c core.autocrlf=false重新克隆repo，它工作了，不需要其他配置。
像这样：

git clone -c core.autocrlf=false https://github.com/any-repo.git

我们的项目最初在Mac上使用LF，但在Windows上它会自动转换为CRLF。我们使用eslint，它在每一行代码下面加了下划线，直到我重新克隆它。

我在工作树中有CRLF行结尾，在存储库中有LF行结尾，因为项目文件夹刚刚从Windows机器复制到Linux机器上Git 1.8.3。这是我如何将行结尾重置为LF：

• git status返回所有已更改文件的列表
• git diff忽略行尾并返回“真正”更改的文件
• comm -3比较列表并返回不在git diff列表中的git status列表文件
• git checkout将这些文件重置为HEAD

comm -3 <(git status --porcelain --untracked-files=no | cut -c4- | sort) <(git diff --name-only | sort) | xargs git checkout HEAD --

merge.renormalize配置设置可能有用。