Как сменить CRLF на LF или LF на CRLF в VS Code

Почему EOL создаёт огромный diff без видимых изменений

Конец строки — это реальные байты файла. В LF используется один символ line feed, а в CRLF — carriage return плюс line feed. Большинство редакторов визуально скрывают разницу, поэтому человек видит те же строки, а Git считает каждую строку удалённой и добавленной заново. Проблема особенно заметна при работе одного репозитория между Windows, WSL, Linux-контейнером и CI. В самом VS Code активный тип окончания строки виден в строке состояния и его можно сменить для текущего документа. Но одиночное переключение не решает командную проблему, если Git при checkout снова преобразует файл. Git официально поддерживает EOL-политику через атрибуты `text` и `eol`: репозиторий может нормализовать текст в LF в индексе и задавать LF/CRLF для working tree по типам файлов. Поэтому сначала решите, меняете ли вы один документ в редакторе или правило всего репозитория.

Совет: Если Git показывает «весь файл изменён», сначала проверьте индикатор EOL и сравните diff. `git diff --ignore-space-at-eol` можно использовать как дополнительный диагностический тест, но не как доказательство причины.

Как изменить EOL без смешивания с другими правками

1. Сохраните или временно уберите функциональные изменения. Нормализацию line endings лучше делать отдельным commit, чтобы review не потерял смысловые изменения.
2. Откройте файл в VS Code и нажмите `CRLF` или `LF` в правой части строки состояния. Выберите новый вариант и сохраните файл.
3. Проверьте Git diff. Если изменён почти весь файл, убедитесь, что это ожидаемая EOL-конвертация и внутри строк нет случайных изменений.
4. Для репозитория создайте или исправьте `.gitattributes`. Распространённая политика — нормализовать текст в LF и явно оставить CRLF для `.bat`/`.cmd`, если это необходимо проекту.
5. Согласуйте `core.autocrlf` с правилами репозитория. Не задавайте глобальную настройку наугад: она влияет на другие проекты и может конфликтовать с `.gitattributes`.
6. После изменения политики проверьте checkout на Windows и Linux/WSL или хотя бы CI, чтобы формат не «прыгал» между средами.

Предупреждение: Не делайте массовую EOL-нормализацию в том же commit, где меняете логику: blame и code review станут почти бесполезными.

Когда выбирать LF, CRLF и .gitattributes

• Один файл должен быть LF. Индикатор EOL в VS Code. Локальная конвертация файла
• Весь репозиторий должен иметь единый EOL.gitattributes. Воспроизводимая политика для команды
• Batch-файлам нужен CRLF, остальному LF. Правила по расширениям в .gitattributes. Разные EOL по типам файлов
• Git сам меняет EOL при checkout. Проверка core.autocrlf + .gitattributes. Устранение конфликтующих правил

Почему .gitattributes лучше личной настройки редактора

Настройка VS Code действует на вашем компьютере, а `.gitattributes` хранится в самом репозитории и едет вместе с кодом. Это особенно важно в mixed-команде, где один разработчик использует Windows, другой Linux, а сборка идёт в контейнере. Git позволяет хранить EOL-политику в `.gitattributes`, например `* text=auto`, а для отдельных типов файлов явно задать `eol=lf` или `eol=crlf`. Такой подход уменьшает зависимость от личных настроек редактора. При этом `.gitattributes` не заменяет понимание `core.autocrlf`: глобальная настройка Git может влиять на другие репозитории и исторически быть причиной путаницы. Если правила уже есть, не добавляйте вторую противоречащую политику. Сначала прочитайте существующий файл, посмотрите `git check-attr` для конкретного пути и только затем меняйте поведение. После изменения правил Git рекомендует контролируемую нормализацию через `git add --renormalize .`; выполняйте её из чистого рабочего дерева и отдельным commit.

Важно: Источником истины для командного EOL лучше сделать репозиторий, а не личные User Settings VS Code.

Что делать, если после переключения EOL приложение перестало работать

Большинство современных языков нормально воспринимают LF и CRLF, но есть скрипты и инструменты, чувствительные к байтам. Shell-скрипт с CRLF на Linux может получить неожиданный carriage return в shebang или командах; старый Windows-инструмент, наоборот, может ожидать CRLF. Поэтому для исполняемых scripts разумно закреплять тип EOL по расширению или назначению. Если проблема появилась после массовой конвертации, откройте конкретный файл, проверьте его EOL и восстановите правило из `.gitattributes`. Не путайте EOL с кодировкой: UTF-8/Windows-1251 описывают символы, а LF/CRLF — границы строк; изменение обоих параметров одновременно делает диагностику сложнее. В проектах с Docker/WSL проверяйте именно файлы, которые монтируются и выполняются внутри Linux-среды. Это снижает риск «работает на Windows, падает в контейнере» из-за невидимого carriage return.

Важно: Для shell scripts, Docker entrypoint и подобных файлов LF обычно критичнее, чем для обычного исходного кода.

Как не получить бесконечный diff из-за EOL

Если строки снова меняются после checkout или коммита, проблема уже не только в строке состояния VS Code. Сравните локальную настройку редактора с правилами Git и репозитория, затем проверьте, есть ли `.gitattributes`. Для команды надёжнее хранить правило окончания строк рядом с кодом, чем рассчитывать на одинаковые пользовательские настройки у всех разработчиков. После изменения политики сделайте отдельную нормализацию и не смешивайте её с функциональным кодом: так review остаётся читаемым. Batch-файлы Windows и некоторые служебные форматы могут требовать CRLF, поэтому единое LF-правило не следует применять без исключений.

Проверка после смены EOL

• Строка состояния показывает ожидаемый LF или CRLF.
• Git diff соответствует только нормализации окончания строк.
• `.gitattributes` не конфликтует с существующими правилами.
• Скрипты запускаются в целевой ОС/контейнере.
• Новый checkout не создаёт массовый незакоммиченный diff.

Что учитывать

Конец строки — это реальные байты файла. В LF используется один символ line feed, а в CRLF — carriage return плюс line feed. Большинство редакторов визуально скрывают разницу, поэтому человек видит те же строки, а Git считает каждую строку удалённой и добавленной заново. Проблема особенно заметна при работе одного репозитория между Windows, WSL, Linux-контейнером и CI. В самом VS Code активный тип окончания строки виден в строке состояния и его можно сменить для текущего документа. Но одиночное…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Basic editing). Пример и формулировки — редакция N1RO на 2026-09-20.

• Basic editing
• gitattributes Documentation — text and eol