Если Git на вашем Mac внезапно помечает практически каждый файл как измененный, возможно, из-за преобразования окончаний строк рабочая копия отличается от версии, отслеживаемой Git. Сначала проверьте репозиторий, прежде чем изменять или восстанавливать файлы. Затем используйте подходящие для macOS настройки Git и выполняйте перенормализацию только после защиты любых реальных правок. Git рекомендует хранить текст с окончаниями LF; в руководстве для macOS используется core.autocrlf input. Руководство GitHub по окончаниям строк

Почему из-за окончаний строк каждый файл может выглядеть измененным?

Символ окончания строки обозначает конец каждой строки: в стиле Unix LF используется один символ, тогда как в стиле Windows CRLF используется возврат каретки плюс перевод строки. Если Git или редактор меняет окончания строк во всей рабочей копии, Git может сообщать о масштабных изменениях файлов, даже если сам текст выглядит одинаково. Git может нормализовать текст до LF в своем индексе и применять различные окончания при извлечении файлов в зависимости от конфигурации и .gitattributes. Документация Git по gitattributes

Проверьте репозиторий перед исправлением

Откройте Терминал, перейдите в репозиторий и проверьте его статус и настройки окончаний строк:

git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol

Команда конфигурации может ничего не вывести, если значение не задано. Параметр --show-origin помогает определить, какой конфигурационный файл задает настройку. В выводе git ls-files --eol сравните окончания в индексе (i/) и рабочем дереве (w/); значение mixed указывает на смешанные окончания. Значение attr/ показывает применимые атрибуты. В документации Git этот вывод описывается как диагностика индекса, рабочего дерева и атрибутов окончаний строк. Документация Git по git-ls-files

Также проверьте наличие фактических правок перед тем, как продолжить. Если вы найдете нужные изменения, закоммитьте их или скопируйте в безопасное место. Не используйте сплошное восстановление или сброс (restore/reset) для исправления окончаний строк: эти команды могут уничтожить вашу работу. С бинарными файлами следует соблюдать особую осторожность, поскольку преобразование окончаний строк может повредить данные, если Git сочтет их текстом. Документация Git по git-config

Задайте разумное значение по умолчанию для macOS

Для работы с Git во всех репозиториях на вашей системе установите рекомендуемую для macOS настройку:

git config --global core.autocrlf input

При значении input Git нормализует CRLF в LF при добавлении текста, не преобразуя файлы с LF в CRLF при извлечении. Эта настройка не определяет правила для абсолютно каждого файла: атрибуты репозитория могут задавать поведение по типам файлов, а атрибуты Git text и eol управляют нормализацией и окончаниями строк при извлечении. Руководство GitHub для конкретных платформ и Справочник Git по конфигурации

Если проблема касается только одного проекта, отдайте предпочтение правилам .gitattributes этого проекта вместо изменения глобальной конфигурации ради одного репозитория. Распространенная отправная точка — * text=auto; конкретные форматы можно закрепить за LF или CRLF, в то время как бинарные форматы должны быть помечены как binary. Например, скриптам командной строки обычно требуется LF, тогда как некоторым файлам проектов Windows необходим CRLF. Правильные шаблоны зависят от инструментов репозитория и участников проекта. Примеры gitattributes в документации Git

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Выполняйте перенормализацию только после проверки изменений

Изменение конфигурации или атрибутов не гарантирует, что существующие файлы сразу же станут согласованными. Документированная процедура обновления от GitHub сначала сохраняет или коммитит текущую работу, затем выполняет git add --renormalize . и проверяет полученный статус. Инструкции GitHub по обновлению

После того как вы безопасно сохранили свои правки и утвердили правила репозитория, проиндексируйте нормализацию и детально проверьте, что именно предлагает Git:

git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached

Не коммитьте автоматически. Просмотрите проиндексированный diff, особенно обращая внимание на неожиданные бинарные или сгенерированные файлы. Если в нем по-прежнему видны изменения содержимого, которые вы не планировали, остановитесь и проверьте затронутые пути и их значения attr/ с помощью git ls-files --eol; исправьте правила в атрибутах перед повторным индексированием. Перенормализация может вызвать большой обоснованный diff, если в репозитории ранее хранились несогласованные окончания, поэтому при необходимости согласуйте коммит с нормализацией с коллегами.

Если файлы остаются измененными

Окончания строк — лишь одна из возможных причин. Проверьте существенные различия в проиндексированных или непроиндексированных изменениях (diffs), убедитесь, не переписал ли файлы редактор, и проверьте фильтры или атрибуты для конкретных файлов. Если git ls-files --eol сообщает i/lf и w/crlf, убедитесь, требует ли какой-либо атрибут или настройка CRLF намеренно. Если выводится mixed, определите, какие файлы имеют смешанные окончания и являются ли они текстовыми, прежде чем выполнять нормализацию. Механизмы безопасности Git могут предупреждать о необратимых преобразованиях, но они не могут определить, был ли файл ошибочно классифицирован как текст. Справочник Git по конфигурации

Практическая последовательность действий такова: защитите правки, проверьте core.autocrlf и git ls-files --eol, выберите единые правила для проекта, затем выполните перенормализацию и просмотрите diff. Это устранит лишний шум от окончаний строк, сохранив за вами контроль над любыми реальными изменениями содержимого.

Источники