我已经克隆了行尾不一致的存储库。我添加了一个.gitattributes，它为我要标准化的文件设置了text属性。现在，当我提交更改时，我收到消息：
warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.
如何让git为我规范化文件的工作副本？最好我想让git标准化整个工作树。
我已经克隆了行尾不一致的存储库。我添加了一个.gitattributes，它为我要标准化的文件设置了text属性。现在，当我提交更改时，我收到消息：
warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.
如何让git为我规范化文件的工作副本？最好我想让git标准化整个工作树。
Answers:
使用Git客户端2.16和更高版本，现在有一种更简单的方法来执行此操作。只需使用：
git add --renormalize .
注意：最好使用干净的工作区进行此操作。有关详细信息，请参见：
error: unknown option 'renormalize'
git --version说什么？我想它早于2.16，并且您需要升级。HTH
git status返回类似内容nothing to commit, working tree clean
对于使用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
现在，行尾在您的工作树中将是正确的。
.gitattributes首次添加或更改设置时，此方法有效，但如果工作树具有不同的EOL（至少对于MsysGit则没有），则该方法无效。为此，它似乎已工作git rm --cached -r .，然后git reset --hard工作了（警告：破坏了您的工作树）。来自help.github.com/articles/dealing-with-line-endings。
git add .在删除索引后执行操作（注意工作目录中以前未跟踪的任何内容）。
git read-tree --empty; git add .变体要谨慎。使用.gitignore时将忽略的所有跟踪文件都将被删除。该文档现在建议git add --renormalize .
确保存储库中没有任何待处理的更改：
$ 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
--eolto选项git ls-files（不再是新选项，但是有些人甚至在2018年底仍在使用Git 1.7！）
该.gitattributes设置只会影响新的提交。如果此存储库未发布历史记录（没有其他历史记录依赖于此存储库），则您可能需要遍历整个历史记录。在Unix / Linux中，您可以结合使用dos2unix(1)来修复所有文件find(1)，并使用历史记录重写filter-branch（请参见git书中的讨论）甚至可以清理项目的全部历史记录。
在新克隆上要格外小心。与可能有克隆的任何人联系，并建议他们您想做什么。
如果.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上的说明均无法正常工作。相反，这些步骤对我们有用：
情况：
还将LFS跟踪文件的-crlf更改为-text，不确定是否需要。
该merge.renormalize配置设置可能是有用的。