Git commit后未手动操作却自动新增空行是什么原因

这类凭空出现的空行基本都和不可见字符的自动处理逻辑有关，常见诱因有三类：

• 行尾符（EOL）自动转换不匹配
  Git默认带有core.autocrlf配置，会在检出、提交文件时自动转换行尾格式：Windows环境下该配置默认值为true，会把类Unix系统的LF行尾转成Windows的CRLF格式；跨系统协作时如果没有统一行尾规则，Git提交时自动修改的行尾符会被Bitbucket的diff引擎识别为内容变更，视觉上就表现为多了空行。部分第三方Git客户端、预处理钩子也会自带行尾自动转换逻辑，触发同样的问题。
• 编辑器/钩子自动补全空行
  绝大多数通用代码规范要求文本文件末尾保留1个空行，很多编辑器默认开启「保存时自动补全文件末尾空行」「保存时自动删除行尾多余空格」的功能，操作时你没有手动加空行，但保存文件的瞬间编辑器已经自动修改了空白字符，提交时这些变更会被Git完整记录。如果仓库配置了pre-commit代码规范钩子，钩子也可能自动修正不符合规范的空行、行尾空白，生成你没主动操作的变更。
• diff视图的视觉误判
  Bitbucket的PR评审页会高亮所有内容变更，包括肉眼不可见的行尾空格、制表符、换行符差异，很多时候你看到的“新增空行”其实只是某行末尾多了个空格，并不是真的新增了整行空白，打开编辑器的「显示不可见字符」开关就能看到实际的差异点。

排查修复方案 #

• 先执行git config --get core.autocrlf查看本地行尾转换配置，跨平台协作场景建议统一把该值设为input（提交时自动转LF，检出时不转换），避免不同系统的行尾格式冲突。
• 在仓库根目录添加.gitattributes文件，通过规则强制锁死所有文本文件的行尾格式，比如添加* text=auto eol=lf规则，要求所有文本文件统一使用LF行尾，从根源上避免Git自动转换行尾带来的异常diff。配置完成后执行git add --renormalize .把仓库内现有文件按规则重新归一化，提交后就能消掉之前遗留的幽灵空行变更。
• 打开编辑器的不可见字符显示功能，确认是否存在编辑器自动补空行、误加行尾空白的情况，可以配合pre-commit钩子统一处理空白字符规则，避免无意义的空白变更进入提交记录。

内容的提问来源于stack exchange，提问作者Tomasz Stępnik