git的换行

Posted on Edited on In

背景

在写一个VBS程序时发现CRLF换行风格会报错.
于是想到尽管目前的软件对换行方式兼容性还ok,
如果不理清git的管理方式,那将后患无穷.

配置项

core.autocrlf

有3种值

  • true, checkout CRLF, commit LF
  • input, checkout as-is, commit LF
  • false, checkout as-is, commit as-is

从文档上看默认值是 false.

建议开发前检查模式

1
2
3
git config --global --get core.autocrlf # clone前检查
git config --get core.autocrlf          # clone后检查
git config --system --get core.autocrlf # clone后检查值从哪里继承过来(.git/config里找不到值)

配置

1
git config core.autocrlf input

应用场景

设定

  1. linux电脑运行CRLF代码会报错
    1. 比如行尾的变量 xxx^M 与行中的变量 xxx 无法匹配
  2. windows电脑运行LF代码会报错
    1. 比如文件头部的一句注释,在windows看来注释掉了整个文件
  3. false模式 + 提交前检查文件换行风格,简称为 手动管理

开发方策略

  1. windows

    1. 跑项目时设置为 true 可无忧无虑
    2. 贡献代码给linux, true 可无忧无虑, input 稍有遗憾(重新clone时自己不能跑)
    3. 贡献代码给windows,必须 手动管理

  2. linux

    1. 敢用 true 的都是不嫌麻烦的狠人
    2. 跑项目时无论什么模式,都需要 手动检查,不能保证云端一定是LF的
    3. 贡献代码给linux, true 和 input 都可以,但前面 true 已经拉了黑名单
    4. 贡献代码给windows,必须 手动管理

运行方策略

  1. windows

    要求所有贡献者都使用 手动管理

  2. linux

    建议所有贡献者不要使用 手动管理

总结

通常情况下

  1. windows适合 true 模式
  2. linux适合 input 模式

许多默认情况下

  1. 此时使用的是 false 模式,linux给linux开发,windows给windows开发一般不会出什么问题
  2. 但如果有跨平台的问题,建议转换成已知问题: 通常情况下

windows给windows开发的特殊情况

  1. 意识不到使用的是 false 模式才最有问题,建议先转换成已知问题 通常情况下 踩踩坑

参考

  1. 配置项为core.autocrlf
  2. 官方对于autocrlf的说明