Бранчи в Figma v2
В этой версии было добавлено описание про секции, а так же немного переработан сценарий раскатки бранчей. Приятного прочтения.
Работа с бранчами (ветками) в Figma — это мощный инструмент для управления версиями и внесения изменений в дизайн-систему или проект. Эта функция позволяет создавать временные копии (ветки) основного файла, вносить изменения, а затем сливать их обратно в основной файл после утверждения.
Что такое бранчинг в Figma?
Бранчинг в Figma позволяет команде работать над изменениями в отдельной ветке файла, не затрагивая основной файл (main). Это удобно для работы над новыми функциями, экспериментов с дизайном или внесения изменений, которые могут потребовать предварительного обсуждения и утверждения.
Создание, удаление и т.п.
Создание бранча: в файле нажимаем на стрелку рядом с неймингом файла и далее Create branch.
Бранч может создать любой дизайнер, однако при мёрдже ветки, должен получить аппрув от владельца файла.
Так же с официальных источников Figma:
Как создавать, удалять и выполнять другие базовые операции с бранчами описано и показано так же и на YouTube.
О работе с бранчами
Когда создавать бранч?
Бранчи создаются почти всегда когда приходит новая задача, вне зависимости от ее назначения, даже если вы хотите просто сделать целевой вариант который в прод никогда не пойдет.
Когда не создавать бранч?
Бранчи не создаются, когда можно внести изменения сразу в актуальные макеты которые есть уже на проде (к примеру когда необходимо поправить в тексте ошибку), а в макетах этого нет. Но помните, что другие бранчи в таком случае также придется обновить.
В общем, бранч не создается только тогда, когда вы на 100% уверены, что изменения возьмутся в работу сразу и их никто не будет согласовывать. Но как только требуется согласование, сразу создавайте бранч.
Обновления и конфликты
При работе с бранчами могут возникать конфликты и обновления. Давайте разберем их по порядку:
- Обновления — это когда вы в основном файле изменили область, которую в бранче не трогали. В таком случае просто принимайте обновления из основного файла;
- Конфликт — это когда вы изменили в основном файле область, которую редактируете в бранче (или наоборот). Тогда возникает конфликт, и вам нужно решить, что сохранить: версию с макетами из основного файла или версию с макетами из бранча. Будьте очень внимательны при выборе версии для сохранения.
Этапы работы с бранчем
По умолчанию предполагается, что вы работаете в файле, где у вас лежат только актуальные макеты, в идеале с примененной схемой версионирования, но на всякий случай начнем и с него. Далее описан процесс работы:
- Определяем актуальные макеты, которые полностью соответствуют проду и создаем под них отдельную страницу(ы). Когда все макеты перенесены, запоминаем простое правило: никогда не трогаем эту зону, только через бранчи;
- (Если есть semver) Присваиваем актуальным макетам/разделам версию. Синхронизации макетов с разработкой не будет, не пытайтесь;
- Создаем бранч, присваиваем имя, выполняете задачу, проводите груминг, согласовываете и тп;
- Странице(ам) присваивается имя в формате nameSpace[версия] (например, «Постчекаут [1.0.0]») или [номер задачи]имя задачи;
- Когда работа завершена, ждем пока фича появиться на проде;
- Когда фича вышла на проде и вы ее увидели, только тогда можно опубликовать бранч;
- Актуальные макеты изменены и у всех одна и та же ссылка, ваши макеты соответствуют проду!;
- (Если есть semver) После публикации поднимаем соответствующую версию макета или раздела, и записываем изменения в журнал изменений, так же не забываем в истории изменений тоже прописать версию и изменения. Пример на скриншоте ниже;
Нюансы
Чего не стоит делать!
- Ни в коем случае не заливайте несогласованные бранчи в актуальные макеты, иначе потом придется делать откат. А если вы еще и 3+ бранча залили, то возникнет целая история с откатами;
- Нельзя копировать компоненты с привязками в другие бранчи; связи останутся, и у вас потом даже Restore не будет доступен, что создаст кучу проблем;
- Нельзя вручную менять актуальные макеты, иначе возникнут конфликты с бранчами, и их придется устранять. Можно править только обдуманно, осознавая, что и зачем вы делаете;
- Всегда учитывайте, соответствуют ли макеты проду и что сейчас находится в разработке;
Очень старый бранч
Если у вас есть очень старый бранч, например, полугодовой давности, в котором много конфликтов, то самым идеальным способом будет создать новый бранч и сделать задачу еще раз. В противном случае придется принимать все обновления и устранять конфликты, что чаще всего просто не получается.
Если задача не ушла в прод
Если задача не уходит долгое время в прод, то тут уже по вашему усмотрению предполагается действовать. Если вы уверены на все 100%, то можете бранч убрать в архив, если не уверены, то лучше оставьте. Ресурсы закрытые бранчи все равно не потребляют.
Откат изменений
Если вам по какой то причине надо восстановить какую либо версию, то тут две развилки события:
- Если вам надо восстановить последний бранч, то вы просто идете в историю и его от туда восстанавливаете, так как он последний опубликованный, то у вас по факту ничего не сломается и просто вернетесь к предыдущей версии;
- Но если же к примеру вам надо восстановить третий (третий просто пример) с конца опубликованный бранч (иначе говоря удалить изменения с того именно бранча), то вы должны понимать, что после этого бранча было опубликовано еще два, и откатить измения не затронув двух последних не получиться. По этому самый лучший способ, это просто создать новый бранч и восстановить, то что вам необходимо и выкатить бранч.
Совет: не опубликовывайте бранч пока он не появиться на проде, как только появился, тогда и опубликовывайте, это позволит вам избежать данный событий.
Секции
При работе с секциями нужно быть предельно аккуратными или избегать их использования вовсе. Почему? Секции объединяют смысловые блоки и служат для обозначения статуса разработки. Изменения внутри этих блоков могут привести к тому, что система при возникновении конфликта подсвечивает всю секцию, что затрудняет понимание, какие именно изменения были внесены. Однако при аккуратном редактировании макетов этой проблемы можно избежать. Либо просто не использовать секции, чтобы избежать таких ситуаций.
Рекомендации
- Частое обновление веток: регулярно обновляйте свои ветки, чтобы быть в курсе последних изменений в основном файле;
- Создавайте ветки для значительных изменений: не используйте ветки для мелких изменений, которые можно внести прямо в основной файл, но только тогда, когда это требуется разработкой;
- Коммуникация с командой: обсуждайте важные изменения с командой, чтобы избежать конфликтов;
- Использование описательных названий веток: давайте веткам информативные названия, чтобы было понятно, какие изменения они содержат;
Если нет доступа к бранчам
Если ваш план в Figma не включает в себя бранчи, то схема следующая:
- Есть страница с актуальным user flow из макетов, который соответствует продукту;
- Для изменений создается отдельная страница в разделе «In Progress», где производится вся работа с макетами. Это может быть как файл, так и страница в файле;
- Далее, если получены все подтверждения, эти изменения вносятся (повторяются все те же действия, что и в черновике) в актуальные макеты с присвоением соответствующей версии и тп;
- После завершения внесения изменений макеты из раздела «In Progress» переносятся в архивный файл, чтобы их можно было потом при необходимости достать. Рекомендуется также сохранять там же макеты, которые были до изменений;
Итог
Работа с бранчами в Figma позволяет команде дизайнеров работать более организованно и эффективно, обеспечивая контроль над изменениями и их управлением. Это улучшает процесс разработки и позволяет всем участникам проекта оставаться на одной волне, имея на выходе всегда актуальные макеты.
🚀 Подписывайтесь, чтобы узнать то, чего не знают другие! Уникальные инсайты и редкие темы для вашего роста и вдохновения! 💡
Привет. У меня такой вопрос возник.
Представим, что продукт еще не в проде, мы только его разрабатываем, но разрабатываем сразу несколько объемных сценариев.
Соответственно, ты только приступаешь к макетам и актуальными их назвать пока сложно.
Если делать все в ветках, то локальные компоненты, которые, возможно, будут пересекаться, будут находиться в разных файлах и при мердже задублируются.
Также общий сценарий команде придется смотреть в разных вкладках, а для их открытия нужны будут разные ссылки.
При этом если мы начнем делать сразу в мастере макеты, то не факт, что они в первозданном виде 1-в-1 заедут на прод.
Вот тут я че-т законфьюзился) Был ли такой кейс, есть ли решение?
Привет! Да был такой кейс, в таком случае если все новое, то допускается делать без веток до тех пор пока у тебя не появиться первая МВП версия. Как только ты ее выкатишь, вот тогда нужно будет двигаться по веткам. Я свою историю (такую же как у тебя) делал без ветки (потому что разницы никакой по факту пока что), ну и я делал один, по этому мне не сильно было принципиально. А вот у тебя из-за того что несколько человек работают, тогда проще намного будет пока делать без веток до первой версии.