Ветки проекта

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

Скажем, в интернет-магазине нужно добавить рекомендации товаров. Вместо того чтобы править main и рисковать всем проектом, вы заводите ветку, доводите функцию до готовности и только потом вливаете её обратно.

Как это работает

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

Создание ветки

Кнопка Branching Options рядом с текущей веткой в меню веток.

Коммиты

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

Как сделать коммит

Что изменилось в коммите

Все коммиты собраны в разделе Branch History: время, автор и сообщение. Список ищется и фильтруется по авторам и датам.

Щелчок по коммиту открывает страницу Commit View:

• Изменённые файлы — в левой панели помечены серой точкой, сразу видно, какие части проекта затронуты.
• Сравнение до и после — в центре построчное сравнение YAML: красным удалённое и изменённое, зелёным добавленное.
• Итог коммита — сверху сводка: сколько файлов изменено, сколько строк добавлено (+) и удалено (−).

Что можно сделать с коммитом

• View Commit — открыть подробности.
• Restore Branch to Commit — вернуть ветку к состоянию этого коммита. Создаётся новый коммит, возвращающий проект назад: пригодится, если последнее изменение что-то сломало.
• Copy Commit ID — скопировать идентификатор коммита, чтобы сослаться на него в переписке с командой.

Коммиты, снимки и версии

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

Подробности — на странице про снимки и версии.

Слияние

Слияние переносит изменения из одной ветки в другую. Обычно из ветки с функцией — обратно в main, когда функция готова к выкатке.

Допустим, в вашей ветке два коммита — Commit 1 и Commit 3, а в main за это время появился Commit 2 от коллеги. Слияние выглядит так:

Можно и наоборот — подтянуть свежие коммиты из родительской ветки в свою:

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

Под капотом работает Git. Проект хранится как репозиторий YAML-файлов (собственный код — как файлы Dart); каждое свойство проекта отображается в YAML, и различия Git считает по этим файлам.

Как начать слияние

На панели инструментов: Branching → Branching options → Merge.

Откроется окно слияния из нескольких панелей.

Верхняя панель

Здесь видно, какие ветки сливаются, и в каком направлении:

• Parent → Child — подтянуть изменения из родительской ветки в дочернюю, чтобы ветка с функцией не отставала.

  

• Child → Parent — отправить готовую функцию наверх, в родительскую ветку.

  

Ошибки проверки YAML появляются, когда результат перестаёт быть корректным для FlutterFlow — из-за ручных правок или из-за самого слияния. Например, в проекте две страницы, и каждая ветка независимо удалила свою: после слияния страниц не осталось ни одной. Конфликта по строкам нет, а ошибка есть. Щелчок по ошибке открывает нужный файл, некорректные строки подчёркнуты красным. Пока такие ошибки не устранены, слияние не завершить.

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

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

Либо, не выходя из слияния, откройте проект, внесите изменения и продолжите.

• После слияния — довести слияние до конца, а ошибки разобрать в проекте позже.

Остальные элементы верхней панели:

• Cancel — отменить слияние и отбросить всё, что вы уже разобрали в этой сессии.

• Merge — завершить слияние. Доступно, когда конфликтов и ошибок YAML не осталось; ошибки проекта завершению не мешают.

• Bulk Accept Changes — под стрелкой рядом с Merge. Принять все изменения одной ветки разом, если заранее известно, чья версия главнее.

  

Левая панель

Все файлы проекта в формате YAML — простом текстовом формате для описания настроек. Во время слияния по ним удобно разбирать, что изменилось.

Фильтры:

• All Files — все файлы проекта, включая нетронутые.
• Files with Changes — только те, что изменились хотя бы в одной ветке.
• Files with Conflicts — только конфликтующие: изменения одной ветки противоречат изменениям другой.

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

Правая верхняя панель

Сравнение файла в двух ветках бок о бок, с кнопками принятия и предпросмотром.

• Accept Change — принять изменения выбранной ветки.
• Значок глаза — открыть файл в редакторе FlutterFlow и посмотреть, как изменение выглядит: цвет темы проще оценить глазами, чем по названию в файле.

Правая нижняя панель

Итоговый результат слияния — то, что получилось после применения логики Git. Файл можно прочитать и поправить руками, есть конфликт или нет.

Git старается объединить изменения сам. Если какие-то строки согласовать не получается, он помечает конфликт маркерами:

• <<<<<<< — начало изменений другой ветки;
• ======= — граница между ветками;
• >>>>>>> — конец конфликта, изменения текущей ветки.

После правок нажмите Save Changes. Красная кнопка сброса вернёт файл к состоянию до вашего вмешательства.

Разбор конфликтов

Конфликт возникает, когда один и тот же участок проекта поменяли несколько человек.

Например, Алиса и Боб работают над одним проектом и оба правят одну кнопку:

Если первой вливается ветка Алисы, её изменения применяются без вопросов. Когда следом вливается ветка Боба, возникает конфликт: текст и цвет уже изменены.

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

• принять все изменения одной ветки;

  

• выбрать отдельные изменения из любой ветки;

  

• править YAML вручную — тогда важно устранить и ошибки проверки YAML, если они появились.

Затем нажмите Merge.

Права на уровне веток

Участникам проекта можно назначать роли Editors и Mergers отдельно для каждой ветки.

Настройка: Settings & Integrations → Project Setup → Collaboration → Branch-Level Access.

• Editors правят проект напрямую, работая в этой ветке.
• Mergers могут только вливать в неё другие ветки. Это то, что нужно для защищённых веток: править напрямую нельзя, изменения попадают туда только слиянием.

Закрытие ветки

Ветку закрывают, когда она сделала своё дело — обычно после того, как её изменения влиты в main или в ветку разработки. Регулярная уборка неактивных веток держит проект в порядке.

Закрытая ветка пропадает из списка активных, но её можно восстановить в течение 30 дней.

Восстановление ветки

Откройте меню Branch Filter и включите Show Closed Branches. Найдите нужную ветку — она откроется в новой вкладке. Там в меню Branching Options выберите Restore Branch.

Частые вопросы

Чем YAML-файлы помогают при слиянии?

• В них лежат настройки, описания ресурсов и свойства проекта, поэтому изменения в файлах прямо отражают изменения в проекте.
• Формат простой и иерархический — изменения и конфликты видно даже в сложных файлах.
• Их можно править руками прямо во время слияния.
• Это текст, поэтому Git отслеживает их как обычный код и несколько человек могут работать параллельно.

Почему после слияния появились не все изменения?

Слияние в Git — не копирование содержимого одной ветки в другую. Это сведение двух версий документа относительно общей отправной точки.

Допустим, вы и коллега правите один проект:

• обе ветки начинались с одного состояния — это общий предок;
• вы внесли изменения в Branch A;
• коллега — в Branch B.

При слиянии Branch B в Branch A Git сравнивает, что изменилось в каждой ветке относительно общего предка. Если изменены разные места, ветки сходятся сами. Если одно и то же место изменено по-разному — это конфликт, и разбирать его придётся вручную.

Что ещё стоит знать:

• Нет конфликтов ≠ нет изменений и тем более не значит, что в проекте нет ошибок.
• Ошибки проекта — не сбой FlutterFlow. Они сообщают, что при слиянии данные сведены неудачно: изменения применились, но результат стоит перепроверить.
• Изменение, которое вы уже приняли или отклонили при слиянии, при следующем слиянии тех же веток как различие не появится — так и задумано.

Например, вы влили Branch B в Branch A, и изменение C из Branch B попало в Branch A. Потом вы отменили C прямо в Branch A. При повторном слиянии Branch B в Branch A Git не покажет C снова: для него оно уже слито.

Как лучше. Держите историю веток короткой: после слияния закрывайте влитую ветку. Если нужно доработать то, что уже влито из Branch B в Branch A, не возвращайтесь в Branch B, а ответвитесь от Branch A заново. Так истории веток не переплетаются, поведение слияний остаётся предсказуемым, а различия — читаемыми.