Git中core.autocrlf与.gitattributes text=auto是否采用相同启发式？

让我来拆解一下你关于Git换行符处理的两个问题，都是非常实用的细节点：

两种场景是否采用相同的启发式判断？ #

是的，这两种场景下Git使用的是同一套文本/二进制启发式判断逻辑。

不管是通过.gitattributes里的* text=auto触发换行符规范化，还是通过全局配置core.autocrlf=true触发，Git都会用相同的规则来识别文件类型：

• 检查文件中是否包含NULL字节（二进制文件常见特征）
• 统计非ASCII字符的占比
• 其他基于文件内容的特征判断

只有被判定为文本文件的内容，Git才会执行换行符的规范化操作；二进制文件会被直接跳过，不做任何换行符转换。

Windows上core.eol=native时，core.autocrlf=true是否等价于.gitattributes中的* text=auto？ #

两者在文本文件的换行符转换行为上高度相似，但并非完全等价，核心差异体现在这几个方面：

• 作用范围不同：

  • core.autocrlf=true是全局Git配置，会应用到你本地所有的Git仓库；
  • .gitattributes是仓库级配置，仅作用于当前仓库，还能提交到仓库中，让所有协作开发者共享相同的换行符规则。

• 优先级不同：
  .gitattributes的规则优先级高于全局的core.autocrlf配置。如果仓库中存在.gitattributes，它的设置会覆盖core.autocrlf的行为，哪怕全局配置已经开启了autocrlf=true。

• 细粒度控制能力不同：
  .gitattributes可以针对特定文件类型单独定义规则，比如给Shell脚本设置*.sh text eol=lf，确保跨平台一致性；而core.autocrlf是全局统一规则，无法针对单个文件或文件类型做差异化配置。

简单来说：在Windows环境下（core.eol=native即CRLF），单看对普通文本文件的“拉取转CRLF、提交转LF”这个核心行为，两者效果一致，但从配置的灵活性、共享性和优先级来看，它们并不完全等价。

内容的提问来源于stack exchange，提问作者andrew.rockwell