Проблема: крупные файлы не помещаются в обычную историю Git или долго загружаются в поездке. Решение: настройте Git LFS на удалённом Mac по этапам — проверьте репозиторий и доступ, скачивайте только нужные объекты, контролируйте диск и заранее отрепетируйте перенос проекта.

Инструкция подойдёт независимым разработчикам, которым нужно поддерживать репозитории с моделями, графикой или бинарными зависимостями.
Она пригодится дизайнерам и инженерам, которые подключаются к удалённой macOS с iPad или лёгкого ноутбука.
Ещё один адресат — технические фрилансеры, которым важно передавать проект при смене города или устройства.

Сначала определите, что именно занимает репозиторий

Git LFS имеет смысл, когда проект хранит крупные версии файлов, которые должны оставаться частью истории разработки: например, исходники графики, видео, модели или бинарные ресурсы. Он не ускоряет любой репозиторий автоматически и не заменяет резервное копирование. Если проблема только в том, что рабочая папка разрослась из-за временных сборок, сначала исключите их из версионирования, а не переводите в LFS.

Различайте причины, прежде чем менять правила проекта:

  • Большой репозиторий в целом. Проверьте, какие объекты действительно нужны для вашей задачи. Сокращение первоначальной загрузки Git и загрузка LFS-объектов — отдельные процессы: параметры частичного клонирования относятся к Git-объектам, а выбор файлов LFS регулируется отдельно. Подробности о параметрах клонирования описаны в документации Git.
  • Отдельные крупные файлы. Для GitHub обычный Git предупреждает о файлах размером свыше 50 MB и блокирует добавление файла свыше 100 MB; эти ограничения относятся к обычному хранению в Git, а не означают, что любой LFS-файл можно загрузить без ограничений платформы. Сверяйте требования к крупным файлам с правилами GitHub для репозиториев и ограничениями Git LFS.
  • Частые повторные загрузки. Определите, какие каталоги нужны для текущего задания. Если вы каждый раз получаете весь набор моделей, хотя работаете с одной сценой, проблема может быть в стратегии выборки, а не в удалённом Mac.
  • Необходимость настольных приложений. Если файлы нужно открыть в редакторе или среде сборки под macOS, удалённый Mac может быть полезен именно как рабочая среда. Сам Git LFS не предоставляет графический редактор и не гарантирует, что конкретное приложение корректно откроет файл.

Можно ли использовать Git LFS на удалённом Mac? Да, если на Mac установлены Git и Git LFS, у вашей учётной записи есть доступ к репозиторию и его LFS-хранилищу, а выбранная схема аутентификации поддерживается платформой. Сам факт, что git clone завершился без ошибки, ещё не подтверждает, что LFS-объекты доступны и рабочая копия содержит настоящие файлы, а не указатели.

Выберите режим загрузки по задаче и пропускной способности

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

  • Полная загрузка LFS-объектов. Подходит, если проект должен быть готов к работе без уточнения, какие ресурсы понадобятся позже, а локального диска достаточно. Недостаток — вы расходуете канал и место также на материалы, которые могут не понадобиться в текущей задаче.
  • Выборочная загрузка по путям. Подходит, когда вы знаете нужные каталоги и хотите получить рабочие материалы без всего архива. В Git LFS для fetch предусмотрены фильтры включения и исключения; уточните синтаксис и поведение в документации команды git lfs fetch.
  • Клонирование репозитория без немедленной выдачи всех LFS-файлов. Уместно для первичной проверки проекта или краткой задачи, если вы готовы отдельно запросить нужные объекты и затем заполнить ими рабочую папку. Не считайте такой клон полноценной копией для автономной работы: проверьте, что файлы, требуемые приложению, действительно доступны локально.

Для выборки можно использовать, например:

git lfs fetch --include="Assets/**"
git lfs checkout

Эта пара команд подходит лишь тогда, когда каталог действительно содержит нужные вам файлы и настроен удалённый репозиторий. Если проект использует другие пути, замените шаблон и проверьте результат командой git lfs ls-files. Не переносите фильтры из примера в рабочий сценарий без проверки: при неверном шаблоне можно получить код, но не нужные ресурсы.

Подготовьте репозиторий и Mac без риска для основной ветки

Для новой среды сначала зафиксируйте исходное состояние проекта и работайте в тестовой ветке или временной копии. Настройка track задаёт шаблоны файлов для дальнейшего отслеживания; она не превращает автоматически все ранее сохранённые Git-файлы в LFS-объекты. Синтаксис и сохранение правил в .gitattributes описаны в официальной документации git lfs track.

Начните с проверки локальных инструментов и установки Git LFS по официальной инструкции проекта:

git --version
git lfs version
git lfs install

Затем выполните подготовку в таком порядке:

  • Уточните источник проекта. Возьмите правильный адрес репозитория и проверьте, какая схема используется для Git: HTTPS или SSH. Доступ к коду не равен автоматически доступу к LFS-хранилищу.
  • Проверьте место на диске. До клонирования изучите свободное пространство и текущую занятость диска. Не используйте размер удалённого репозитория как прогноз: рабочая копия, кэш LFS, приложения и экспортированные материалы могут занимать место независимо друг от друга.
  • Клонируйте тестовую копию. Убедитесь, что проект открывается и обычные Git-операции выполняются ожидаемо. Если используете частичное клонирование, отдельно проверьте поведение LFS: оно не заменяет выборочную загрузку LFS-объектов.
  • Добавьте правила в тестовой ветке. Для новых файлов задайте нужные шаблоны, проверьте .gitattributes, затем добавьте и зафиксируйте правило вместе с тестовым файлом.
  • Проверьте полный цикл. На копии выполните отправку тестового изменения, получите изменения на другой рабочей копии и убедитесь, что в каталоге находится реальный файл, а не текстовый указатель.

Не меняйте LFS-правила в основной ветке только ради того, чтобы «исправить» уже разросшуюся историю. Если файлы ранее коммитились непосредственно в Git, перевод истории требует отдельного плана миграции и согласования с участниками: простого добавления нового шаблона недостаточно. Сначала проверьте, кто ещё работает с репозиторием, какие ветки и инструменты сборки используют старую схему, и как участники получат обновлённую историю. Без такого согласования изменение формата хранения может остановить работу команды или привести к разным представлениям одного и того же проекта.

Разделите проверку доступа, загрузку и восстановление

У Git-операций и Git LFS могут отличаться точки обращения и этапы аутентификации. Сервис может сначала принять запрос к репозиторию, а затем отдельно проверить доступ к LFS-объектам. Описание обнаружения LFS-сервера есть в документации server discovery, а обмена данными для авторизации — в документации Git LFS authentication.

Как настроить учётные данные, чтобы не входить в систему при каждом действии? Следуйте поддерживаемому вашей платформой способу сохранения учётных данных и не записывайте секреты в репозиторий, скрипты, общие заметки или файлы проекта. Если используется HTTPS, проверьте, что сохранённый доступ разрешает операции с LFS, а не только чтение кода. При SSH также убедитесь, что удалённый LFS-сервис принимает используемую схему доступа: наличие SSH-доступа к Git само по себе не доказывает успешную авторизацию для LFS.

После настройки проверяйте этапы отдельно:

  • git clone или git fetch проверяет доступ к Git-репозиторию;
  • git lfs fetch проверяет получение нужных LFS-объектов;
  • git lfs checkout выдаёт уже полученные объекты в рабочую папку;
  • открытие файла в целевом приложении проверяет, что восстановлен пригодный материал, а не только успешно выполнена команда.

Для первичной диагностики зафиксируйте адрес удалённого репозитория, выбранный способ доступа, текст ошибки и команду, на которой она возникла. Не отправляйте в журнал пароли, токены и приватные ключи. Если ошибка возникает только на шаге LFS, вернитесь к правам для LFS-сервиса и его адресу, а не переустанавливайте Git без причины.

Восстанавливайте загрузку при нестабильной сети через повторную проверку

Что делать, если Git LFS не скачивает файлы на удалённый Mac? Сначала выясните, завершился ли Git-запрос, обращение к LFS-серверу или выдача файлов в рабочую папку. Сохраните сообщение об ошибке, проверьте подключение и повторно запросите необходимые объекты; после этого отдельно выполните checkout и проверьте контроль целостности.

В гостинице или кафе не рассчитывайте, что частично завершившаяся передача автоматически продолжится с того же байта: поведение зависит от клиента, сервера и причины обрыва. Безопаснее исходить из того, что состояние надо проверить повторным запросом. Не удаляйте рабочую копию и локальный кэш только потому, что команда однажды завершилась ошибкой — сначала установите, какие объекты уже получены и не изменились ли локальные файлы.

Используйте такой порядок восстановления:

  • повторите команду загрузки для требуемого набора файлов;
  • проверьте список LFS-файлов и фактическое наличие материалов;
  • запустите git lfs fsck, чтобы проверить LFS-объекты; описание проверок приведено в документации git lfs fsck;
  • откройте ключевые файлы в том приложении, для которого они предназначены;
  • при повторной ошибке сохраните журнал диагностики и сверяйте его с правилами доступа, путём к LFS-серверу и сетевыми ограничениями текущей сети.

При разборе сбоя различайте сетевую проблему и ошибку прав. Если соединение обрывается до ответа сервера, повторная проверка сети и загрузки уместна. Если сервер отвечает отказом, повторение команды без исправления доступа обычно не помогает: нужно проверить разрешения, срок действия учётных данных и соответствие удалённого адреса. Если команда сообщает об успешной загрузке, но файл отсутствует в рабочей папке, проверьте, запускался ли checkout и подходит ли выбранный шаблон включения.

Как вести большой репозиторий в поездке, когда связь нестабильна? Подготовьте список нужных файлов до выхода из надёжной сети, загрузите их заранее и оставьте проект в состоянии, которое можно проверить без повторного клонирования. Если выполнить передачу нельзя, не удаляйте исходную копию и не начинайте рискованную миграцию, пока не восстановите доступ к серверу и не подтвердите, какие изменения существуют только локально.

Контролируйте место и очищайте кэш только после проверки

Место на удалённом Mac расходуется из нескольких независимых источников: рабочая папка проекта, локальные LFS-объекты, приложения, временные экспорты и другие проекты пользователя. Чтобы не спутать их, сначала посмотрите сведения о путях хранения командой git lfs env, затем измерьте рабочую папку и нужный каталог объектов средствами macOS, например du -sh. Свободное место проверяйте отдельно, например df -h ..

Сделайте замеры до загрузки и после неё в одинаковом состоянии проекта, записав, какие файлы и приложения были добавлены между проверками. Это не даст точного прогноза для следующего проекта, но позволит понять, какие каталоги создают основную нагрузку именно в вашей среде. Если место растёт после экспорта, а не после получения объектов, очистка кэша LFS проблему не решит. Если рабочая копия и кэш велики одновременно, проверьте, действительно ли вам нужно держать оба набора локально.

Не очищайте кэш в середине незавершённой работы, если эта копия — единственная доступная. Команда git lfs prune удаляет локальные объекты, которые Git LFS считает неиспользуемыми по своим правилам; до запуска изучите условия удаления в документации git lfs prune. Перед очисткой убедитесь, что важные коммиты отправлены, нужные файлы получены из удалённого хранилища, а локальные изменения не потеряются.

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

Перенесите проект до окончания аренды или смены устройства

Заранее решите, что именно переезжает: коммиты, незакоммиченные изменения, LFS-объекты, настройки окружения и локальные экспортированные файлы. Само клонирование репозитория на другой Mac не гарантирует, что туда попадут незакоммиченные изменения и все крупные файлы.

Перед завершением работы:

  • проверьте git status и сохраните нужные изменения в коммитах либо передайте их отдельным согласованным способом;
  • отправьте коммиты и LFS-объекты, затем на принимающей стороне выполните получение изменений и нужных файлов;
  • проверьте переменные окружения и локальные настройки, не помещая секреты в историю Git;
  • запустите git lfs fsck и откройте ключевые материалы в целевом приложении;
  • не удаляйте исходную среду, пока принимающая копия не прошла проверку.

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

Как перенести и очистить проект после завершения работы с Git LFS? Сначала подтвердите, что на новом устройстве доступны код и реальные LFS-файлы, а не только указатели; затем проверьте локальные изменения и нужные настройки. После успешной передачи отдельно удалите временные экспорты и очистите неиспользуемые объекты по правилам prune. Если продолжаете работать на удалённом Mac, оставьте там только актуальную рабочую копию и данные, которые действительно нужны для следующей задачи.

Примите решение по проверочному списку

Отметьте подходящий вариант для каждого условия. Последний отмеченный пункт задаёт рабочую схему; если ни один вариант для проекта не подходит, сначала исправьте причину, а не переносите репозиторий вслепую.

  • [ ] Файлы — версии моделей, графики или бинарных ресурсов, которые должны храниться вместе с историей проекта. Выбор: настройте Git LFS в тестовой ветке и проверьте отправку и получение. Если речь о временных сборках или экспортах, не включайте их в LFS без необходимости.
  • [ ] Для текущего задания заранее известны нужные каталоги, а место на диске ограничено. Выбор: примените выборочную загрузку по путям и проверьте реальные файлы в рабочей папке. Если нужные материалы заранее неизвестны и работа должна продолжаться без сети, сначала проверьте запас места и только затем получите полный набор.
  • [ ] Код клонируется, но запрос LFS отклоняется сервером. Выбор: проверьте права для LFS и сохранённые учётные данные. Не повторяйте загрузку без изменений доступа; если же LFS-объекты скачаны, но приложение не видит их, отдельно проверьте checkout и шаблоны путей.
  • [ ] Сеть нестабильна, но локальная копия уже содержит нужные файлы. Выбор: продолжайте работу с этой копией и сохраните локальные изменения. Не удаляйте её ради повторного клонирования; если ключевых объектов нет, отложите рискованную передачу до надёжного соединения.
  • [ ] Скоро заканчивается аренда или проект переходит на другое устройство. Выбор: отправьте коммиты и LFS-объекты, проверьте файлы и приложение на принимающей стороне, затем очищайте исходную среду. Если принимающая копия проверку не прошла, сохраните исходный Mac до устранения проблемы.
  • [ ] Нужны macOS-приложения и доступ к проекту с лёгкого устройства, но работа зависит от надёжной сети. Выбор: рассмотрите удалённый Mac после репетиции полного цикла. Если требуются физические подключения, автономность или постоянная работа без сети, выбирайте локальный компьютер.

Сопоставьте удалённую среду с локальной до переноса

Удалённый Mac помогает оставить проект и инструменты в одной рабочей среде, к которой можно подключаться с лёгкого устройства. Но такое решение зависит от сети: слабый канал может затруднить передачу новых LFS-объектов, удалённая сессия не заменяет резервную копию, а локальные изменения требуют отдельного контроля перед окончанием аренды. Локальный Mac избавляет от зависимости от соединения при доступе к уже загруженным файлам, но его нужно возить, защищать и поддерживать в актуальном состоянии.

Перед сменой схемы проверьте также, как вы будете передавать обычные файлы вне Git: например, экспортированные материалы, конфигурации и архивы для заказчика. Выбор способа передачи файлов на удалённый Mac должен учитывать, что включено в репозиторий, а что существует только в рабочей папке. Условия удалённого доступа и аренды можно отдельно оценить на странице удалённого Mac mini.

Главное условие для крупного репозитория — проверить не только Git-команды, но и доступ к LFS, фактическое восстановление файлов, расход диска и перенос незакоммиченной работы. Если тестовая репетиция выявила проблемы с сетью, хранением или передачей проекта, сначала устраните их и лишь затем переносите рабочий процесс.

Если после такой проверки вам нужна временная macOS-среда для проекта, но не хочется везти собственный Mac и вручную готовить запасное устройство, изучите варианты удалённой работы с Mac. Для продолжительной нагрузки, физической периферии или автономной работы локальный компьютер может оставаться более подходящим решением.