如果没有关于存储库中有哪些文件的信息（纯源代码、图像、可执行文件……），就很难回答这个问题：）

除此之外，我认为您愿意在工作目录中默认使用 LF 作为行尾，因为无论您在 Windows 或 Linux 上工作，您都愿意确保 .git
存储库中的文本文件具有 LF 行尾. 确实比抱歉更安全....

但是，还有一个更好的选择：受益于 Linux 工作目录中的 LF 行结尾、Windows 工作目录中的 CRLF 行结尾和存储库中的 LF 行结尾。

由于您部分地在 Linux 和 Windows 上工作，请确保core.eol设置为native并core.autocrlf设置为true.

然后，将.gitattributes文件的内容替换为以下内容

* text=auto

这将让 Git 在提交和签出时为您处理自动换行符。二进制文件不会被更改，检测为文本文件的文件将看到动态转换的行尾。

但是，由于您知道存储库的内容，您可以帮助 Git 帮助他从二进制文件中检测文本文件。

如果您从事基于 C 的图像处理项目，请将.gitattributes文件内容替换为以下内容

* text=auto
*.txt text
*.c text
*.h text
*.jpg binary

这将确保扩展名为 c、h 或 txt 的文件将以 LF 行结尾存储在您的存储库中，并且在工作目录中将具有本机行结尾。Jpeg
文件不会被触及。所有其他人都将受益于与上述相同的自动过滤。

为了更深入地了解这一切的内部细节，我建议你深入阅读 Githubber 的 Tim Clem 的这篇非常好的文章 “Mind the end of
your line” 。

作为一个真实世界的示例，您还可以查看此
提交.gitattributes，其中演示了对文件的这些更改。

更新考虑到以下评论的答案

我实际上不想在我的 Windows 目录中使用 CRLF，因为我的 Linux 环境实际上是一个共享 Windows 目录的 VirtualBox

说得通。感谢您的澄清。在这种特定情况下，.gitattributes文件本身是不够的。

对您的存储库运行以下命令

$ git config core.eol lf
$ git config core.autocrlf input

由于您的存储库在 Linux 和 Windows 环境之间共享，这将更新这两个环境的本地配置文件。core.eol将确保文本文件在结帐时带有 LF
行结尾。core.autocrlf将确保文本文件中的 潜在 CRLF（例如，由复制/粘贴操作产生）将在您的存储库中转换为 LF。

或者，您可以通过创建包含类似于以下内容的文件来帮助 Git 区分什么 是文本文件：.gitattributes

# 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仍应将 workdir 视为干净。