Git 统一文件换行符确保本地拉取后哈希一致

Git 默认的 core.autocrlf 机制虽然初衷是为了缓解不同操作系统间的换行符差异，但在对文件哈希值（Hash）有严格一致性要求的场景下，这种“自动转换”反而会带来意想不到的干扰。为了维护一份github远程仓库的笔记，在不同本地拉取后文件的哈希严格一致，需要使用这样的方式：在本地彻底统一使用 LF，并全面禁用 Git 的自动转换行为。

本文将详细记录如何通过配置 Git 和开发工具，达成文件哈希严格一致的终极目标。

1. 为什么需要禁用 Git 的自动转换？

Git 底层通过文件内容的字节流来计算 SHA-1 哈希值。\r\n (CRLF) 和 \n (LF) 在字节层面上是完全不同的。

如果依赖 Git 的自动转换（如 core.autocrlf = true），文件在远程仓库和本地工作区呈现的是两种不同的字节状态。这意味着你本地计算出的文件哈希，将与仓库中记录的哈希不一致。对于需要进行严格文件校验、自动化打包或跨平台脚本执行（例如 Linux 下的 Shell 脚本如果混入 CR 字符会直接报错）的工程来说，这是不可接受的。

因此，我们的策略是：远程仓库是什么样，拉下来就是什么样；本地保存成什么样，推上去就是什么样。没有任何中间商赚差价。

2. Git 配置：关闭所有魔法

第一步是剥夺 Git 篡改文件内容的权力。我们需要在所有的本地主机上执行以下命令，将全局自动转换功能关闭：

git config --global core.autocrlf false

排雷提示： 如果你的项目中存在 .gitattributes 文件，并且其中包含了 * text=auto 这样的指令，它会覆盖你刚才设置的全局属性。为了确保 core.autocrlf false 绝对生效，你需要检查并注释/删除项目根目录下 .gitattributes 中的相关转换规则。

3. 编辑器配置：从源头强制 LF

禁用了 Git 的自动转换后，维护换行符统一的责任就落在了“文件创建者”也就是编辑器身上。我们需要确保无论使用哪台主机，新建的文件都必须是纯正的 LF。

以 VS Code 为例，在 settings.json 中添加：

"files.eol": "\n"