項目團隊最近在代碼中加入了一個新功能，利用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 //禁止混用換行符 “`