项目团队最近在代码中加入了一个新功能，利用flyway工具来管理数据库版本变更。这个工具会记录每次数据库结构的变化，并生成sql文件保存在指定目录中（前提是必须使用flyway进行数据库变更，外部变更无法被它识别）。每次启动时，flyway会检查当前数据库与项目代码中的sql变更版本是否一致。如果一致，系统正常启动；如果不一致，且数据库版本落后，flyway会自动更新数据库，以确保代码在任何环境中运行时数据库都是一致的。否则，系统会报错。数据库中有一张表记录版本信息，如下图所示：
同时，本地代码中有一个文件夹保存每次操作的sql语句，如下图：
通过比较checksum值来判断当前SQL语句和生成数据库的执行语句是否一致，checksum值是通过CRC32计算并处理得出的。
然后问题出现了：团队中的其他成员搭建好flyway后，项目文件生成了两个SQL文件，我通过git拉取这些文件后，启动项目时报错，checksum值不匹配。我对flyway不太了解，根据报错信息，一步步查找，最终发现checksum值是通过CRC32计算的。花了一两个小时才发现文件不一致的问题。奇怪的是，我们都是从git拉取的文件，为什么我的文件会不一致呢？我怀疑可能是文件换行符的问题，于是将那些SQL文件的换行符全部改成了CRLF（Windows中的换行符），结果项目居然能够运行了。关于为什么从git拉取的文件换行符会不一致的原因是：他们使用的是TortoiseGit（小乌龟）这种可视化工具，而我使用的是命令行工具。可视化工具自动配置了文件换行符的自动转换（这是git的一个智能功能，上传时将文件换行符替换为LF，下载时再替换为CRLF，这样保证中心仓库使用unix风格的换行符，而本地能够根据运行环境使用相应的换行符风格），但命令行工具并没有配置这种转换。
解决这个问题的方法也很简单，就是开启git的自动转换功能。
代码语言：JavaScript 代码运行次数：0
运行 复制 “`javascript git config –global core.autocrlf true //开启换行符自动转换 git config –global core.safecrlf true //禁止混用换行符 “`
