Figma Make: как отправить PR с локальным кодом? Процесс для дизайнеров в 2026 году

Локальный код Figma Make не следует считать доступным каждому пользователю. Функция открывается постепенно и требует приложения Figma для Mac в версии Beta. Обычный аккаунт Figma, работа в веб-редакторе или членство в команде сами по себе не подтверждают, что тестовая функция доступна именно вам. Текущий статус и условия описаны в справке Figma о тестируемых функциях.

Какие аккаунт и Mac нужны для работы с локальным кодом? Нужен аккаунт, которому предоставлен доступ к тестированию, приложение Figma для Mac в версии Beta и разрешение открыть целевой Git-репозиторий. Проверяйте доступ именно в аккаунте и приложении, которые собираетесь использовать. Не переносите проект и не меняйте настройки репозитория, пока не убедились, что функция доступна.

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

На практике задержки чаще вызваны не самой правкой дизайна, а условиями вокруг неё:

• Нет доступа к репозиторию. Допуск к тестированию Figma не даёт автоматически прав на чтение или запись кода. Доступ может требовать приглашения, отдельной авторизации или одобрения владельца проекта.
• Неизвестны шаги запуска. Для предпросмотра могут понадобиться зависимости, настройки среды и команда запуска, о которых знает только команда разработки.
• Не согласована ветка. Изменения не должны попадать в основную линию проекта без согласованного порядка работы. Сначала уточните, от какой ветки начинать.
• Тестовая функция меняется. Доступность, интерфейс и поддерживаемые действия могут обновляться. Не обещайте команде срок, исходя из предположения, что условия тестирования останутся неизменными.
• Проверка кода не входит в автоматическую правку. Внешне удачный предпросмотр не подтверждает, что код соответствует дизайн-системе, требованиям доступности и архитектуре проекта.

До открытия проекта выясните у инженера четыре вещи: какой репозиторий нужен, с какой ветки начинать, как запустить предпросмотр и какие проверки обязательны перед передачей. Попросите указать страницу или компонент, который можно менять, а также файлы и настройки, которые следует оставить без изменений.

Figma описывает подключение к существующей кодовой базе в инструкции по настройке локального кода. Сверьте с ней актуальные требования непосредственно перед работой: Beta-функция и её настройки могут изменяться.

Не переносите возможности одной платформы на другую. Figma указывает создание PR в приложении для GitHub. Для GitLab и Bitbucket заранее планируйте переход на соответствующую платформу. Общее описание работы с кодом приведено в материале Figma о локальной кодовой базе.

Что проверить до подключения проекта? Убедитесь, что вам разрешены чтение репозитория и создание ветки, а инженер дал команду запуска и список обязательных проверок. Это позволит разделить проблему с правами или настройкой проекта и результат дизайнерского изменения. Не передавайте коллегам пароли и токены, а при ошибке авторизации попросите владельца проекта проверить предоставленные разрешения.

Шаг 1. Проверьте тестовую функцию

Откройте Beta-приложение под аккаунтом, который будет использоваться для работы, и убедитесь, что сценарий локального кода доступен. Если функции нет, остановитесь и проверьте допуск. Повторная авторизация в репозитории, установка зависимостей или копирование файлов не заменят предоставление доступа.

Шаг 2. Выберите подходящий способ открыть проект

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

При запросе разрешения Git-провайдера проверьте, что авторизован нужный аккаунт и выбран нужный репозиторий. Если проект не отображается, не пытайтесь обходить ограничение. Сначала запросите доступ у владельца репозитория и уточните, как команда управляет разрешениями.

Шаг 3. Запустите предпросмотр

Запустите проект командой, которую согласовали с инженером, и дождитесь загрузки целевой страницы. Сверьте адрес страницы, текст, изображения и основные элементы интерфейса с задачей. Предпросмотр подтверждает, что вы видите страницу в проекте, но не доказывает, что открыта правильная ветка или что сайт готов к публикации.

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

Если предпросмотр не запускается, проверьте доступ к репозиторию, наличие требуемых зависимостей и настройки проекта. Не делайте вывод, что проблема вызвана запросом к Figma Make. Официальный разбор ошибок настройки и способов устранения неполадок помогает проверить причины, связанные со средой и настройкой.

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

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

Используйте предпросмотр и доступные инструменты приложения, чтобы указать нужный элемент и описать желаемое изменение. Затем проверяйте не только внешний вид, но и фактическую разницу в коде. Figma рассказывает о работе с локальной кодовой базой в описании этой функции, однако сгенерированное изменение не следует считать автоматически соответствующим дизайн-системе, доступности интерфейса или архитектуре проекта.

Проверьте следующее:

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

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

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

Шаг 4. Проверьте изменения перед коммитом

1. Убедитесь, что выбрана согласованная исходная ветка.
2. Создайте рабочую ветку по правилам команды и сохраните её название.
3. Просмотрите список изменённых файлов; исключите всё, что не относится к задаче.
4. Сверьте предпросмотр с запросом и проверьте указанные командой состояния страницы.
5. Запустите проверки, которые команда считает обязательными.
6. Если проверка не запускается, зафиксируйте причину для инженера и не отмечайте её как пройденную.
7. Создайте коммит с понятным сообщением и подготовьте краткое описание результата.

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

Как после правок подготовить ветку и PR? Зафиксируйте изменение в отдельной ветке и затем выберите путь, соответствующий платформе: для GitHub Figma указывает создание PR в приложении, а для GitLab и Bitbucket запрос оформляется на самой платформе. В описании укажите цель правки, затронутую страницу, выполненные проверки и вопросы для ревью. Не объединяйте изменения и не публикуйте сайт самостоятельно, если это не входит в ваши полномочия.

После создания запроса приложите контекст, который поможет команде оценить работу: название ветки, краткое описание изменённого интерфейса, способ открыть предпросмотр и результаты проверок. Отдельно перечислите то, что не удалось проверить, и вопросы к инженеру. Не скрывайте незавершённые пункты: отсутствие этой информации может привести к лишним циклам уточнений.

Для GitHub используйте предусмотренный Figma путь создания PR. Затем следуйте обычному процессу команды. О том, как просматривать предлагаемые изменения, можно прочитать в документации GitHub по ревью PR. Для GitLab и Bitbucket создавайте соответствующий запрос на платформе, сверяясь с таблицей выше. Тестовый режим не гарантирует одобрение PR, правильность сгенерированного кода или публикацию результата.

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

Можно ли пройти этот процесс через удалённый Mac, если основной компьютер работает на Windows? Да, при условии, что у аккаунта есть тестовый доступ, в удалённой среде доступно приложение Figma для Mac в версии Beta и вы можете подключиться к нужному репозиторию. Удалённый Mac предоставляет среду macOS, но не меняет тестовый статус аккаунта, права на репозиторий или правила команды.

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

Используйте следующий порядок решения:

• Если тестовый доступ подтверждён, задача ограничена интерфейсом существующего веб-проекта и у вас есть права на репозиторий — можно подключать проект и готовить небольшую правку.
• Если вы работаете в Windows, а задачу можно выполнить только в Mac-версии Beta — сначала подтвердите доступность нужного приложения в удалённой среде. Если это не подтверждено, не привязывайте к ней срок сдачи.
• Если аккаунт не допущен или нет прав на код — отложите работу до получения разрешений. Аренда Mac эти ограничения не снимает.
• Если задача включает серверную логику, инфраструктуру или выпуск продукта — заранее передайте техническую часть инженеру и согласуйте границу дизайнерских изменений.
• Если работу предстоит выполнять постоянно или нужны физические интерфейсы — сравните удалённый доступ с собственным Mac и локальной настройкой проекта.

Для временной задачи аренда Mac может быть альтернативой покупке отдельного устройства, когда действительно требуется Mac-версия Beta. При этом удалённая среда добавляет зависимость от соединения, а доступ к репозиторию и тестовой функции всё равно нужно получать отдельно. Общие сведения о варианте удалённого доступа можно найти на странице MESHLAUNCH. Перед началом отдельно уточните, доступно ли нужное приложение и можно ли подключиться к вашему проекту.

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