Git属性：-text与eol=lf的配置差异及优劣对比

你的需求是：让Git仓库所有检出操作都使用LF换行符，即使在Windows系统且core.autocrlf启用时也生效。下面直接对比你提到的三种配置的核心差异：

1. * -text #

• 核心逻辑：完全禁用所有文件的换行符转换，所有文件都被Git标记为二进制类型。
• 优势：配置简单，彻底跳过Git的换行符处理逻辑，不会有转换带来的意外。
• 劣势：
  • 无法确保检出文件都是LF——如果仓库中原本存在带CRLF的文件，检出后还是CRLF，直接不满足你的需求；
  • Git会把所有文件当二进制处理，无法对文本文件进行正常的diff、merge等文本相关操作，实用性大打折扣。

2. * text eol=lf #

• 核心逻辑：强制所有文件被识别为文本文件，提交时将工作区的任何换行符转成LF存入仓库，检出时保持LF输出到工作区（不受系统默认和core.autocrlf影响）。
• 优势：严格保证文本文件的仓库和工作区都是LF，完全符合你的检出LF需求。
• 劣势：会误将二进制文件（比如图片、压缩包、可执行文件）当作文本处理，提交时Git会修改其中的换行符序列，直接损坏二进制文件，风险极高。

3. * text=auto eol=lf #

• 核心逻辑：Git自动通过启发式判断区分文本/二进制文件：
  • 文本文件：提交时转LF到仓库，检出时输出LF到工作区；
  • 二进制文件：不进行任何换行符转换，保持原文件内容。
• 优势：
  • 完美满足“所有文本文件检出为LF”的需求，同时不会破坏二进制文件；
  • 保留了Git对文本文件的diff、merge等正常支持，实用性最强；
  • 不受core.autocrlf全局配置干扰，确保仓库内换行符统一为LF。
• 劣势：相比前两者配置稍复杂，但这是兼顾安全性和需求的最优解。

总结 #

如果要严格满足你的需求且不引入风险，* text=auto eol=lf是唯一合适的选择。另外两种配置要么无法保证LF检出，要么会损坏二进制文件，都存在明显的缺陷。

内容的提问来源于stack exchange，提问作者Michael Karcher