我在 github 上托管了一个 git 存储库。许多文件最初是在 Windows 上开发的，我不太注意行尾。当我执行初始提交时，我也没有任何 git 配置来强制执行正确的行尾。结果是我的 github 存储库中有许多文件以 CRLF 行结尾。
我现在正在 Linux 上进行部分开发，我想清理行尾。如何确保文件在 github 上使用 LF 正确存储，并且在我的工作副本中有 LF？
我已经设置了一个包含 .gitattributes 的 text eol=LF 文件；那是对的吗？提交并推送后，我可以仅 rm 我的本地存储库并从 github 重新克隆以获得所需的效果吗？
最佳答案
如果没有关于您的存储库中有哪些文件的一些信息(纯源代码、图像、可执行文件等)，回答这个问题有点困难:)
除此之外，我认为您愿意将 LF 默认为工作目录中的行尾，因为无论您在 Windows 还是 Linux 上工作，您都愿意确保文本文件在 .git 存储库中具有 LF 行尾.确实比抱歉更安全......
但是，还有一个更好的选择:受益于 Linux 工作目录中的 LF 行结尾、Windows 工作目录中的 CRLF 行结尾和存储库中的 LF 行结尾。
当您部分使用 Linux 和 Windows 时，请确保 core.eol 设置为 native 并且 core.autocrlf 设置为 true 。
然后，将 .gitattributes 文件的内容替换为以下内容
* text=auto
这将使 Git 在提交和 check out 时为您处理自动换行符。二进制文件不会被更改，被检测为文本文件的文件将看到行尾动态转换。
但是，当您知道存储库的内容时，您可以帮助 Git 并帮助他从二进制文件中检测文本文件。
如果您从事基于 C 的图像处理项目，请将
.gitattributes 文件的内容替换为以下内容* text=auto
*.txt text
*.c text
*.h text
*.jpg binary
这将确保扩展名为 c、h 或 txt 的文件将与 LF 行结尾一起存储在您的存储库中，并且将在工作目录中具有 native 行结尾。 Jpeg 文件不会被触及。所有其他人都将受益于与上述相同的自动过滤。
为了更深入地了解所有这些的内部细节，我建议您深入阅读这篇来自 Githubber 的 Tim Clem 的非常好的帖子 "Mind the end of your line" 。
作为现实世界的示例，您还可以查看此 commit 文件，其中演示了对
.gitattributes 文件的更改。考虑以下评论 更新答案
说得通。感谢您的澄清。在这个特定的上下文中，
.gitattributes 文件本身是不够的。针对您的存储库运行以下命令
$ git config core.eol lf
$ git config core.autocrlf input
由于您的存储库在 Linux 和 Windows 环境之间共享，因此这将更新两个环境的本地配置文件。
core.eol 将确保文本文件在结帐时带有 LF 行结尾。 core.autocrlf 将确保文本文件中的潜在 CRLF(例如由复制/粘贴操作产生)将在您的存储库中转换为 LF。或者，您可以通过创建一个包含类似于以下内容的
.gitattributes 文件来帮助 Git 区分什么是文本文件:# Autodetect text files
* text=auto
# ...Unless the name matches the following
# overriding patterns
# Definitively text files
*.txt text
*.c text
*.h text
# Ensure those won't be messed up with
*.jpg binary
*.data binary
如果你决定创建一个
.gitattributes 文件， 提交它 。最后，确保
git status 中提到了“nothing to commit (working directory clean)”，然后执行以下操作$ git checkout-index --force --all
这将在您的工作目录中重新创建您的文件，考虑您的配置更改和
.gitattributes 文件并替换文本文件中任何可能被忽视的 CRLF。完成此操作后，工作目录中的每个文本文件都将带有 LF 行结尾，并且
git status 仍应将工作目录视为干净的。关于git - 在 git repo 和工作副本中强制 LF eol，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9976986/