Git: 'CRLF will be replaced by LF' — что это значит и как исправить проблему

kirilljsx

В Git часто выскакивает предупреждение ‘CRLF will be replaced by LF’. Это значит, что система автоматически меняет окончания строк в файлах, чтобы они соответствовали стандартам репозитория. Проблема возникает из-за разницы в форматах между Windows (CRLF) и Unix (LF), что приводит к конфликтам при коммитах.

Понимание этой механики поможет избежать лишних изменений в коде и упростит работу в команде. Мы разберем, что происходит на самом деле, и покажем простые способы исправить ситуацию. Это сэкономит время и нервы всем разработчикам.

Что такое CRLF и LF в контексте Git

Окончания строк — это символы, которые обозначают конец каждой строки в текстовом файле. В Windows используется CRLF (Carriage Return + Line Feed, коды 0x0D + 0x0A), а в Unix/Linux/macOS — только LF (Line Feed, 0x0A). Git хранит файлы в репозитории всегда с LF, чтобы обеспечить единообразие независимо от ОС.

Когда вы добавляете файл с CRLF в Git на Windows, система может выдать предупреждение ‘LF will be replaced by CRLF’ или наоборот. Это происходит из-за настройки core.autocrlf, которая управляет автоматической конвертацией. Если она включена, Git меняет окончания при checkout (извлечении) и commit (добавлении). Например, файл с CRLF сохраняется в репо как LF, а при checkout возвращается в CRLF для Windows.

Такая логика полезна для кросс-платформенной разработки, но иногда приводит к “призрачным” изменениям: Git видит файл измененным только из-за окончаний строк. Представьте: вы клонируете репо на Linux, а там файлы с CRLF — скрипты ломаются, потому что Bash интерпретирует \r как часть имени команды.

Вот основные сценарии:

Windows-репо: core.autocrlf = true → CRLF в рабочей папке, LF в репо.
Unix-репо: core.autocrlf = input → LF везде.
Без настройки: возможны конфликты и предупреждения.

Формат	ОС	Символы	Git-поведение с core.autocrlf=true
LF	Unix/Linux/macOS	\n (0x0A)	Сохраняется как LF, checkout без изменений
CRLF	Windows	\r\n (0x0D+0x0A)	Конвертируется в LF при commit, обратно при checkout
CR	Старый macOS	\r (0x0D)	Редко, но Git предупредит

Почему Git ругается на окончания строк

Предупреждение ‘CRLF will be replaced by LF’ появляется при git add или git commit, если в файле смешанные окончания или они не соответствуют ожидаемым. Git проверяет это через core.safecrlf, которая может быть warn (предупреждение), true (блокировка) или false (игнор). Это защита от случайных повреждений файлов.

На практике проблема возникает, когда команда работает на разных ОС: виндовый разработчик коммитит CRLF, линуксовый видит изменения в каждом файле. Или редактор (VS Code, Notepad++) меняет формат незаметно. Результат — дифф полон “пустых” правок, коммиты засоряются, CI/CD падает на скриптах с ^M (символом \r).

Решение лежит в настройках Git и инструментах. Например, git config --global core.autocrlf input на Linux конвертирует CRLF в LF при commit, но не трогает checkout. На Windows true — стандарт. Но лучше стандартизировать проект целиком.

Ключевые причины предупреждений:

Смешанные окончания в одном файле — Git не знает, что делать.
core.safecrlf = true — блокирует коммит с CRLF.
Отсутствие .gitattributes — нет правил для типов файлов.

Для проверки формата используйте cat -A file.txt (покажет ^M для CRLF) или file file.txt в терминале.

Как настроить Git правильно для всех платформ

Настройка core.autocrlf решает 90% проблем, но зависит от ОС. Для Windows ставьте true: Git будет работать с CRLF локально, но сохранять LF в репо. На Unix — input: только commit конвертирует в LF, checkout оставляет как есть. Глобально: git config --global core.autocrlf [значение].

Дополните core.safecrlf warn — это даст предупреждения без блокировки. Но для командного проекта создайте .gitattributes: укажите правила для файлов. Например, *.sh text eol=lf заставит Git всегда использовать LF для шелл-скриптов. Примените: git add --renormalize . и закоммитьте изменения.

EditorConfig (.editorconfig) — универсальный файл для редакторов: end_of_line = lf навяжет LF всем. VS Code, IntelliJ его чтут автоматически. Если репо уже “заразилось”, сделайте чистый клон и перенormализуйте.

Шаги по исправлению:

Проверьте текущие настройки: git config --list | grep crlf.
Установите глобально: git config --global core.autocrlf true (Windows) или input (Unix).
Добавьте .gitattributes:

* text=auto
*.sh text eol=lf
*.py text eol=lf
*.js text eol=lf

Нормализуйте: git rm --cached -r . && git reset --hard.
В редакторе: VS Code → статусбар → CRLF → LF.

Настройка	Windows	Linux/macOS	Эффект
true	Рекомендуется	Не ставить	Автоконверт в обе стороны
input	Не оптимально	Рекомендуется	Только commit → LF
false	Только с .gitattributes	Идеально	Полный контроль

Альтернативы и продвинутые трюки

Если автоконверт бесит, отключите: git config --global core.autocrlf false и полагайтесь на .gitattributes. Для бинарников добавьте *.exe binary. Это предотвратит любые изменения окончаний. В больших репо используйте git config core.preloadindex true для ускорения проверок.

Проверьте изменения: git diff --ignore-cr-at-eol. Для миграции старого репо: создайте скрипт, который проходит по всем файлам, конвертирует в LF и коммитит. Инструменты вроде dos2unix (Linux) или unix2dos (Windows) помогут вручную.

Полезные команды:

git ls-files --eol — покажет статус окончаний для всех файлов.
git config core.safecrlf false — отключить проверки (рискованно).
.editorconfig: добавьте charset = utf-8 и trim_trailing_whitespace = true.

Контроль над окончаниями без головной боли

В итоге предупреждения о CRLF/LF — признак неправильной настройки, но их легко устранить через config и .gitattributes. Главное — договориться в команде о стандартах и проверить редакторы. Останутся нюансы с legacy-файлами или экзотическими ОС.

Дальше можно углубиться в .gitattributes для бинарников или интеграцию с CI, где скрипты требуют строгого LF. Это сохранит репозиторий чистым на годы вперед.