记一次使用pycharm自带的命令行终端进行rebase导致的crlf转换为lf

问题描述：

经历过一次针对Windows server的.net项目，在更改配置文件提交后并部署到服务器，导致服务启动失败，报错为加载配置文件失败，但是仔细对比和服务端和本地的配置文件 ，没有任何区别，然而本地是可以正常启动的，这就头疼了

最终通过对比工具发现，本地与服务端的文件的不同之处是换行符不一样：

 

解释：windows下的换行符为crlf（即\r\n），liunx和mac系统的换行符为lf（即\n）

 

怀疑有可能是因为配置中的core.autocrlf=ture导致的，意思提交时自动将crlf转为lf，目的是为了能够在windows下开发linux项目时做到自动转换，自动兼容在需要部署到linux上运行的工程

如果是针对windows操作系统开发的工程，则要关闭自动转换，即设置core.autocrlf=false，避名在提交时将将crlf转为lf

操作命令为：git config core.autocrlf false

 

但意外的结果是：即使关闭了core.autocrlf，仍然会出问题

 

所以，问题出在哪里？ 经过互联网和大海捞针和仔细的回忆和分析自己的操作过程，功夫不负有心人，发现问题出在了rebase上：

使用Git rebase 命令进行代码合并时，如果期间遇到冲突，使用pycharm的resolve conflict功能时，选择accept yours/theirs，会导致xml文件(web.config)中的crlf换行符，被替换为lf，最终导致.net工程编译失败。

 

然而直接使用命令行git rebase xxx -X theirs/ours进行冲突解决，则不会产生crlf替换为lf的错误

 

 

所以，最终确定问题出在pycharm上，在使用pycharm的解决冲突功能时，即使git关闭了autocrlf，pycharm中仍然会执行crlf转为lf，在在记录一下导致此问题的pycharm版本信息：

PyCharm 2017.2.6

Build #PY-172.4574.33, built on April 10, 2018

Licensed to imsxm.com

 

JRE: 1.8.0_152-release-915-b12 amd64

JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o

Windows 10 10.0

 

在解决这个问题的过程的，费了很多的脑细胞，一步步实验，一步步的排除问题的原因，最终找到了产生问题的本质，每往深挖一点，就得到一点收获，感谢问题带给自己的成长，也庆幸自己不是浅薄的一带而过，要不然虽然问题解决了，但是并未挖掘到问题的本质的话，以后还会犯同样的错误。