Git 行尾配置
内容提要
本文介绍了如何设置Git，使不同操作系统的人可以在同一个仓库中工作，而不会破坏源文件的行尾。通过更改core.autocrlf设置来实现。个人使用可以将core.autocrlf设置为true，仓库可以使用.gitattributes文件来强制设置行尾。通过运行重新规范化命令，可以将行尾规范化。可以通过运行特定命令来纠正工作树中文件的行尾问题。
延伸解读
个人设置与仓库强制设置的区别
文章指出，个人通过core.autocrlf=true设置行尾规范化，但该设置无法强制他人，因此不适合团队协作。仓库级设置使用.gitattributes文件，可以覆盖个人配置，确保所有贡献者遵循统一的行尾规则。这种强制方式更可靠，尤其适合跨平台项目。
规范化后工作树行尾为何不变
运行git add --renormalize后，Git仅将索引中的行尾规范化为LF，而工作树中的文件行尾保持不变。例如，原本CRLF的文件在本地仍是CRLF。这可能导致工作树与索引不一致，需额外步骤修正。
检查与修正工作树行尾的方法
使用git ls-files --eol可查看索引和工作树的行尾状态。若工作树行尾不符合预期，可运行git rm --cached -r .和git reset --hard HEAD来重置工作树，使其与索引一致。注意这会丢弃未提交的更改，操作前应确保工作区干净。
Q&A
如何设置 Git 让不同操作系统的人协作时不破坏行尾？
可以通过更改 core.autocrlf 设置来实现。个人使用时可以将其设置为 true，但这种方式不可强制，因此更推荐在仓库中使用 .gitattributes 文件来强制设置行尾。
core.autocrlf 设置为 true 后，提交文件时行尾会怎样变化？
设置 core.autocrlf 为 true 后，提交文件时 Git 会将行尾规范化为 LF，但本地工作树中的文件行尾保持不变。
如何使用 .gitattributes 文件强制设置行尾？
在项目根目录创建 .gitattributes 文件，例如：* text=auto、*.bat text eol=crlf、*.jpg binary。这些设置会覆盖 core.autocrlf 设置。
运行 git add --renormalize 后，工作树中的文件行尾会改变吗？
不会。运行 git add --renormalize 只会将规范化后的文本文件放入 Git 索引，但不会改变工作树中文件的行尾。
如何查看 Git 仓库中文件的行尾状态？
可以运行 git ls-files --eol 命令查看文件的行尾状态。输出中 i/lf 表示索引中使用 LF，w/lf 或 w/crlf 表示工作树中的行尾。
如何纠正工作树中文件的行尾问题？
可以运行 git rm --cached -r . 和 git reset --hard HEAD 命令来纠正工作树中文件的行尾问题。
