新上手一個項目，克隆了代碼下來搭環境，一路坑。其中一個sh腳本執行不了，報IOException，java日志除了“找不到文件或文件夾”之外看不出任何信息，手動運行腳本才發現是腳本編碼有問題：
應該是有人用windows開發的，提交時未做crlf轉換。我印象中git是會自動轉換crlf的，為何還會出現這種問題呢？下面是搜到的一個解釋：
原文地址：在Git中一定要關注的crlf自動轉換
GitHub 第一坑：換行符自動轉換
如果你已經做出了錯誤的選擇，也不需要重新安裝，可以直接使用命令行來修改設置。很簡單，直接打開這貨自帶的命令行工具 Git Bash，輸入以下命令，再敲回車即可：
git config --global core.autocrlf false
在各操作系統下，文本文件所使用的換行符是不一樣的。UNIX/Linux 使用的是 0x0A（LF），早期的 Mac OS 使用的是 0x0D（CR），后來的 OS X 在更換內核后與 UNIX 保持一致了。但 DOS/Windows 一直使用 0x0D0A（CRLF）作為換行符。（不知道 Bill Gates 是怎么想的，雙向兼容？）
這種不統一確實對跨平台的文件交換帶來麻煩。雖然靠譜的文本編輯器和 IDE 都支持這幾種換行符，但文件在保存時總要有一個固定的標准啊，比如跨平台協作的項目源碼，到底保存為哪種風格的換行符呢？
Git 作為一個源碼版本控制系統，以一種（我看起來）有點越俎代庖、自作聰明的態度，對這個問題提供了一個“解決方案”。
Git 由大名鼎鼎的 Linus 開發，最初只可運行於 *nix 系統，因此推薦只將 UNIX 風格的換行符保存入庫。但它也考慮到了跨平台協作的場景，並且提供了一個“換行符自動轉換”功能。
安裝好 GitHub 的 Windows 客戶端之后，這個功能默認處於“自動模式”。當你在簽出文件時，Git 試圖將 UNIX 換行符（LF）替換為 Windows 的換行符（CRLF）；當你在提交文件時，它又試圖將 CRLF 替換為 LF。
這是一個相當大的坑，Windows 下的中文開發者幾乎都會中招。舉個例子，你在 Windows 下用默認狀態的 Git 簽出一個文件，寫了一行中文注釋（或者這個文件本來就包含中文），然后存盤提交……不經意間，你的文件就被毀掉了。
因為你提交到倉庫的文件已經完全變成了 Windows 風格（簽出時把 UNIX 風格轉成了 Windows 風格但提交時並沒有轉換），每一行都有修改（參見本文開頭的示意圖），而這個修改又不可見（大多數 diff 工具很難清楚地顯示出換行符），這最終導致誰也看不出你這次提交到底修改了什么。
這還沒完。如果其他小伙伴發現了這個問題、又好心地把換行符改了回來，然后你又再次重演上面的悲劇，那么這個文件的編輯歷史基本上就成為一個謎團了。
由於老外幾乎不可能踩到這個坑，使得這個 bug 一直隱秘地存在着。但在網上隨便搜一下，就會發現受害者絕對不止我一個。