Если git pull завершается с ошибкой, хотя проект на вашем Mac выглядит чистым, сначала определите точную причину: возможно, Git защищает локальные или игнорируемые файлы, скрывает изменения в подмодулях или отказывается объединять разошедшиеся истории веток. В Терминале проверьте полный статус репозитория и отслеживание веток, прежде чем изменять файлы или выбирать стратегию слияния (merge) или перебазирования (rebase).

Начните с репозитория и зафиксируйте фактическую ошибку

Откройте Терминал, перейдите в папку проекта и повторите попытку pull только в том случае, если вам нужно воспроизвести сообщение. В современных версиях macOS Терминал по умолчанию использует zsh, а приведенные ниже команды в кавычках работают как в zsh, так и в bash. Руководство Apple по Терминалу

cd "/path/to/your/project"
git status --short --branch
git pull

Замените путь в кавычках на фактическую папку вашего проекта. Полностью прочитайте текст ошибки pull. Сообщение «Your local changes … would be overwritten» указывает на конфликт на уровне файлов. «Divergent branches» или «Not possible to fast-forward» означает, что истории локальных и восходящих (upstream) коммитов разошлись и требуют выбора способа согласования. В графическом клиенте эти проблемы могут выглядеть одинаково, однако они требуют разных действий.

Проверьте файлы, скрытые кратким выводом статуса

Краткий вывод статуса может опускать важные детали. Выполните более полную проверку в режиме только для чтения:

git status --untracked-files=all --ignored=matching --ignore-submodules=none
git diff --
git diff --cached --

Обычно git status сообщает о неотслеживаемых файлах, однако локальная настройка может их скрывать; флаг --untracked-files=all выводит отдельные файлы внутри неотслеживаемых папок. Игнорируемые файлы исключаются из вывода, если их не запросить явно, поэтому --ignored=matching отображает игнорируемые пути, соответствующие правилам исключения. Параметр --ignore-submodules=none указывает команде status выводить изменения в подмодулях, даже если конфигурация в противном случае скрывала бы их. Git документирует эти режимы отображения статуса и отмечает, что игнорируемые пути получают специальный маркер состояния. Документация Git по status

Две команды git diff показывают соответственно отслеживаемые изменения в рабочем дереве и подготовленные (staged) изменения. Они не отображают содержимое игнорируемых или неотслеживаемых файлов. Таким образом, «чистый» результат в графическом интерфейсе, другой папке или отфильтрованном выводе статуса не гарантирует, что видны абсолютно все помехи; используйте Терминал в том же самом репозитории и проверьте конкретный путь, указанный Git. Правила исключения намеренно скрывают подходящие неотслеживаемые файлы из обычного вывода статуса. Документация Git по ignore

Если указанный в ошибке путь игнорируется или не отслеживается, проверьте его перед перемещением или удалением. Не выполняйте git clean, git reset --hard и не перезаписывайте путь в качестве быстрого способа диагностики: эти команды могут уничтожить локальные результаты работы или файлы. Если в нем содержится что-то нужное, сделайте отдельную копию или сохраните данные другим способом перед устранением коллизии.

Проверьте подмодули и флаги индекса

Репозиторий с подмодулями может выглядеть чистым на верхнем уровне, в то время как внутри подмодуля присутствуют локальные правки, неотслеживаемые файлы или переключен другой коммит. Расширенная команда проверки статуса, приведенная выше, указывает Git не игнорировать состояние подмодулей. Вы также можете перейти в каталог указанного подмодуля и выполнить там git status --untracked-files=all; у каждого подмодуля есть собственное рабочее дерево и свой статус.

В более редких случаях индекс Git может содержать флаги, влияющие на обработку путей. Флаг assume-unchanged указывает Git предполагать, что файл соответствует индексу, а skip-worktree позволяет не обновлять путь во время таких операций, как pull. Проверить нестандартные записи можно с помощью команды:

git ls-files -v

Она выводит отслеживаемые пути с тегами индекса; строчные буквы могут обозначать записи с флагом assume-unchanged, а буква S указывает на skip-worktree. Используйте эту информацию только для диагностики, а не как руководство к очистке. Не сбрасывайте флаги вслепую по всему репозиторию; если указан проблемный путь, проверьте его содержимое и настройки sparse-checkout в проекте, прежде чем менять состояние индекса. Документация Git по update-index

Если сообщение указывает на расхождение веток

Чистое рабочее дерево не означает, что история вашей локальной ветки совпадает с восходящей (upstream). Проверьте, какая ветка активна и что именно она отслеживает:

git branch --show-current
git branch -vv
git status --short --branch

Вывод статуса и веток покажет, опережает ли локальная ветка восходящую, отстает от нее или их истории разошлись. Команда git pull сначала получает удаленные изменения (fetch), а затем интегрирует настроенную восходящую ветку. Ее поведение по умолчанию (fast-forward-only) прерывается, когда локальная и удаленная ветки разошлись; это обусловлено политикой работы с историей, а не наличием незакоммиченных изменений в файлах. Документация Git по pull

Если есть локальные коммиты, выберите метод, соответствующий правилам совместной работы в вашем проекте: rebase применяет локальные коммиты поверх восходящей ветки, а merge объединяет истории и может создать коммит слияния. Если вы не уверены, уточните это у мейнтейнеров репозитория или следуйте командным договоренностям. Не стоит задавать глобальные настройки pull или выполнять жесткий сброс (force-reset) ветки только ради того, чтобы заглушить ошибку: ни одно из этих действий не дает понимания, что должно произойти с этими коммитами.

Используйте ошибку для выбора следующего шага

Конфликт файлов требует проверки указанного пути, включая игнорируемые файлы и подмодули. Сообщение о расхождении веток требует анализа истории коммитов и выбора стратегии их интеграции. Если статус остается чистым, но в ошибке фигурирует конкретный путь, убедитесь, что Терминал запущен в нужной рабочей копии, проверьте этот путь напрямую и убедитесь в отсутствии соответствующих флагов индекса. Текст сообщения об ошибке — это самый полезный инструмент диагностики: сохраняйте локальные файлы и коммиты в безопасности, пока не поймете, с каким именно отказом со стороны Git вы столкнулись.

Источники