Ветвление

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

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

к сведению

Хотя все пользователи могут получить доступ к меню ветвления и создавать коммиты, создание новых веток поддерживается только в планах Growth и выше.

warning

Создание ветки здесь не создаёт её на GitHub. Ветки остаются и управляются исключительно в FlutterFlow. Вы также можете узнать больше о управлении пользовательским кодом на GitHub.

Обзор ветвления

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

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

примечание

Важно понимать, что такое слияние. Слияние не выполняет «объединение» данных между ветками. Вместо этого Git merge примиряет различия (diffs) между ветками. При слиянии Git сравнивает изменения, внесённые в новую ветку, с основной веткой и применяет эти изменения напрямую.

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

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

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

Чтобы создать новую ветку из текущей ветки, просто перейдите к кнопке Варианты ветвления рядом с текущей веткой в меню Ветвление.

подсказка

Вы можете создать новую ветку из любой существующей ветки, однако чаще всего новые ветки создают из main

Коммиты

Коммит — это по сути сохранённый снимок вашего проекта в определённый момент времени. Когда вы вносите изменения в проект (например, добавляете новые виджеты, изменяете действия или настраиваете интеграции), вы можете создать коммит, чтобы сохранить эти изменения. Каждый коммит хранит запись о том, что было изменено, и служит историей версий для вашей ветки, что позволяет легко увидеть, что изменилось, и откатиться к предыдущим версиям при необходимости.

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

Чтобы создать коммит, выполните следующие шаги:

Лучшие практики для коммитов

• Часто создавайте коммиты: Сохраняйте работу регулярно, чтобы изменения отслеживались, и у вас была подробная история версий. Вы можете использовать сочетание клавиш (cmd + enter) для более быстрой итерации!
• Используйте понятные сообщения: Всегда указывайте осмысленные сообщения коммитов, объясняющие, что было сделано.
• Тестируйте перед коммитом: Убедитесь, что проект работает как ожидается, перед созданием коммита с существенными изменениями.

Просмотр изменений в коммитах

После создания коммита вы можете увидеть список всех коммитов в разделе История ветки. Здесь каждый коммит отображается с временной меткой, пользователем, внесшим изменения, и сообщением коммита. Вы также можете искать и фильтровать коммиты по конкретным пользователям и диапазону дат.

Чтобы увидеть изменения в коммите, просто кликните на него. Вы попадёте на страницу Просмотр коммита, где сможете:

• Просмотреть изменённые файлы: В левой панели файлы, которые были изменены, отмечены серой точкой, что позволяет легко заметить, какие части проекта обновлены.
• Сравнить до и после: Центральная панель предоставляет боковое сравнение diff YAML для каждого изменённого файла. Строки, выделенные красным, указывают на удалённое или изменённое содержимое, в то время как строки зелёного цвета показывают newly added или обновлённое содержимое.
• Просмотреть статистику коммита: В верхней части страницы вы увидите краткий обзор того, сколько файлов было изменено, и общее количество добавленных (+) или удалённых (-) строк.

Варианты коммитов

Варианты, предоставляемые для каждого коммита, следующие:

• Просмотр коммита: Этот вариант позволяет просмотреть детали конкретного коммита.
• Восстановить ветку до коммита: Этот вариант позволяет откатить вашу ветку к предыдущему коммиту. Он создаёт новый коммит, который сбрасывает ветку к состоянию выбранного коммита. Это особенно полезно, если недавний коммит ввёл проблемы, и вам нужно вернуться к стабильной точке в истории проекта.
• Копировать ID коммита: Каждый коммит имеет уникальный ID. Этот вариант позволяет скопировать ID коммита, что полезно для ссылки на конкретные коммиты при сотрудничестве с членами команды.

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

FlutterFlow предлагает несколько способов сохранения состояния вашего проекта в конкретные моменты времени.

• Снимки создаются автоматически по мере редактирования проекта. Думайте о них как об автоматических резервных копиях, к которым вы можете вернуться в любой момент.
• Версии и коммиты, с другой стороны, — это вручную создаваемые контрольные точки. Хотя оба служат похожей цели, коммиты предлагают больше гибкости, позволяя просматривать конкретные изменения, внесённые в каждый коммит. Если вы используете план, поддерживающий ветвление, рекомендуется использовать коммиты для лучшего отслеживания и контроля версий.

Вы можете узнать больше о снимках и версиях здесь.

Слияние

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

Предположим, ваша ветка функции содержит два коммита: Commit 1 и Commit 3 (это ваши изменения) и Commit 2 (сделанный коллегой в основной ветке). Слияние будет выглядеть как на изображении ниже:

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

Во время слияния Git сравнивает изменения, внесённые в обе ветки; если изменения не пересекаются или не конфликтуют, ветки автоматически объединяются. Если есть конфликты (например, обе ветки изменили свойство одного и того же виджета), вам нужно будет их разрешить, прежде чем слияние сможет быть завершено.

Несколько моментов, на которые стоит обратить внимание

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

Слияние в FlutterFlow использует Git под капотом для расчёта различий между файлами проекта. Каждый проект подкреплён репозиторием YAML-файлов (за исключением пользовательского кода, который отображается как Dart-файлы). Эти YAML-файлы напрямую соответствуют различным свойствам проекта, и Git рассчитывает различия между этими файлами, чтобы выявить конфликты слияния.

Планы на будущее

• Документация на основе наведения: Отображение полезных подсказок для полей YAML (запланировано перед релизом в продакшен).
• Ошибки YAML в строке: Показ ошибок непосредственно в файле для более быстрого исправления (запланировано перед релизом в продакшен).
• Упрощённый YAML: Сделать YAML-файлы и ошибки более удобными и понятными для пользователя.
• Улучшенные инструменты визуального diff: Предоставить более интуитивные виды для сравнения изменений.
• Улучшения пользовательского опыта: Непрерывно дорабатывать рабочие процессы слияния и элементы UI.
• Оптимизации производительности: Улучшить скорость при инициации слияний.

Инициация слияния

Чтобы инициировать слияние, перейдите в Панель инструментов > выберите Ветвление > Варианты ветвления > выберите Слияние.

При выполнении слияния в FlutterFlow вы увидите экран с несколькими панелями и разделами информации. Вот детали.

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

• Информация о ветках: В верхней части интерфейса слияния вы увидите точно, какие ветки сливаются. У вас есть два варианта направлений слияния:
  • Родитель → Ребёнок: Передаёт изменения вниз из родительской ветки в дочернюю, часто используется для синхронизации ветки функции с родительской веткой.
  • Ребёнок → Родитель: Передаёт функции (или другие изменения) из дочерней ветки вверх в родительскую, обычно делается, когда функция готова к интеграции в родительскую ветку.
• Ошибки валидации YAML: Они возникают, когда результирующие данные не в «FlutterFlow-дружественном» формате — будь то из-за ручных правок или слияний, генерирующих несовместимый YAML. Например, представьте, что в вашем проекте две страницы, и каждая ветка независимо удаляет разную. После слияния страниц не остаётся. Хотя строки кода не редактируются и напрямую не конфликтуют, это приводит к ошибке валидации YAML. Клик по этим ошибкам должен перенаправить вас к конкретному файлу. Недопустимые строки будут подчеркнуты красным в файле, и вы не сможете завершить слияние, пока существуют ошибки YAML.
• Ошибки проекта: Ошибки проекта возникают, когда результат слияния создаёт проблему в вашем проекте. Например, это может произойти, если слияние приводит к тому, что два типа данных имеют одно и то же имя. Эти ошибки нужно разрешить, чтобы обеспечить работу проекта как ожидается. У вас есть несколько вариантов для работы с ошибками проекта:
  • Исправить ошибки во время слияния: Этот подход гарантирует, что объединённый проект будет без ошибок с самого начала. Вот как это сделать:

    • Редактировать YAML-файлы: Обновите YAML-файлы проекта (в правой нижней панели), чтобы исправить проблемы, такие как переименование типа данных, вызывающего конфликт.

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

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

Левая панель

Левая панель отображает все файлы проекта в формате YAML. Файлы YAML (Yet Another Markup Language) используют простой, читаемый для человека формат для определения конфигурационных данных. Они особенно полезны во время слияния, поскольку позволяют напрямую просматривать, понимать и разрешать любые изменения или конфликты в файлах вашего проекта.

• Фильтр файлов: Вы можете использовать фильтры, чтобы сузить список YAML-файлов на основе конкретных критериев:

  • Все файлы (неизменённые файлы): Показывает каждый YAML-файл в проекте, который не имеет изменений.

  • Файлы с изменениями: Отображает только файлы, где изменения были внесены в одной из веток.

  • Файлы с конфликтами: Показывает только файлы, имеющие конфликты слияния, где изменения в одной ветке напрямую противоречат изменениям в другой.

    к сведению

    • Изменение относится к любому обновлению, добавлению или удалению, сделанному в одной из веток. Например, изменение имени поля или свойств виджета.
    • Конфликт возникает, когда одна и та же часть файла изменена в обеих ветках, что делает неясным, какую версию сохранить. Например, если одна ветка меняет цвет Container на синий, а другая — на красный, это создаёт конфликт.

• Поиск файла: Если вы ищете конкретный файл, вы можете использовать строку поиска, чтобы быстро его найти. Это особенно полезно в крупных проектах с множеством файлов.

Клик по файлу в панели открывает его в редакторе, позволяя просматривать, редактировать и разрешать проблемы напрямую.

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

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

к сведению

Правки выделяются с помощью цветовой кодировки зелёного и красного (Git):

• Зелёный указывает на строки или значения, добавленные (или уникальные) в одной ветке.
• Красный указывает на строки или значения, удалённые (или заменённые) этой веткой.

• Кнопка принятия изменения: Быстро принять изменения из одной ветки, если вы знаете, что они правильные.
• Иконка глаза (предварительный просмотр): Открыть или просмотреть файл в конструкторе FlutterFlow, чтобы увидеть, как выглядят изменения. Например, вы можете визуально просмотреть изменение цвета темы, а не просто читать его имя в файле.

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

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

Git пытается автоматически объединить изменения из обеих веток. Если Git не может примирить определённые строки, он отмечает конфликт слияния в файле. Конфликты появляются с специальными маркерами, такими как <<<<<<<, ======= и >>>>>>>.

• <<<<<<<: Отмечает начало изменений другой ветки
• =======: Разделяет изменения вашей текущей ветки от изменений другой ветки.
• >>>>>>>: Отмечает конец конфликта, указывая изменения вашей текущей ветки.

подсказка

Вы можете решить сохранить определённые строки из <<<<<<< (из другой ветки) или >>>>>>> (из вашей ветки) или объединить их вручную.

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

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

Для получения дополнительной информации просмотрите видео ниже.

Разрешение конфликтов слияния

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

Например, представьте, что два разработчика, Алиса и Боб, работают над одним проектом FlutterFlow и оба решают обновить один и тот же виджет кнопки.

Разработчик	Имя ветки	Изменения
Алиса	feature-alice	- Изменяет текст кнопки на "Submit Form"
		- Изменяет цвет кнопки на синий
Боб	feature-bob	- Изменяет текст кнопки на "Send"
		- Изменяет цвет кнопки на зелёный

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

При инициации слияния с помощью Git система пытается автоматически примирить файлы вашего проекта. Любые конфликты, которые нельзя разрешить автоматически, отмечаются для вашего внимания.

Вы можете просмотреть каждый файл с конфликтами слияния и выбрать:

• Принять все изменения из одной ветки.
• Выбрать конкретные изменения из любой ветки.
• Вручную отредактировать YAML-файлы. Обратите внимание, что важно исправить любые ошибки валидации YAML, возникающие из-за ручных правок.

Наконец, завершите слияние, кликнув Слияние.

подсказка

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

Разрешения на уровне ветки

В вашем проекте вы можете назначать конкретные роли, такие как Редакторы и Сливающие, членам проекта для каждой ветки.

Чтобы настроить эти разрешения, перейдите в Настройки и интеграции > Настройка проекта > Сотрудничество > Доступ на уровне ветки.

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

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

Закрытие ветки — это распространённая практика после того, как ветка выполнила свою цель, обычно после того, как её изменения были слиты в другую ветку (например, main или development). Регулярно закрывая неактивные или слитые ветки, вы помогаете поддерживать чистый, эффективный и хорошо организованный проект.

Когда закрывать ветку

• После слияния: Как только изменения ветки слиты в ветку main (или другую целевую ветку), ветку можно безопасно закрыть. Это часто происходит после завершения функции или исправления ошибки.
• Неиспользуемая ветка: Если ветка больше не нужна (например, функция была заброшена или изменения сделаны в другой ветке), её стоит закрыть.

Вот как вы можете закрыть ветку:

Лучшие практики

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

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

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

Чтобы восстановить ветку, откройте меню Фильтр веток и включите Показывать закрытые ветки. Найдите или выберите ветку, которую хотите восстановить, и она откроется в новой вкладке браузера. Затем, в закрытой ветке, откройте меню Варианты ветвления и выберите Восстановить ветку, чтобы реактивировать её.

Часто задаваемые вопросы

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

YAML-файлы играют ключевую роль в управлении и разрешении конфликтов во время процесса слияния, потому что:

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

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

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

Предположим, вы и ваш друг оба внесли изменения в один и тот же проект:

• Вы оба начали с одной исходной версии (это называется общим предком).
• Вы внесли свои изменения в Branch A.
• Ваш друг внес изменения в Branch B.

Когда вы сливаете Branch B в Branch A, Git сравнивает:

• Что изменилось в Branch A с общей отправной точки.
• Что изменилось в Branch B с общей отправной точки.

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

Вот ещё несколько моментов, которые стоит знать:

• Отсутствие конфликтов ≠ отсутствие изменений: «Нет конфликтов» не значит «нет изменений» и определённо не значит, что проект без ошибок.
• Ошибки проекта — не баги: Ошибки проекта сообщают, что вы допускаете ошибки при слиянии данных. Даже если изменения успешно слиты, ошибки проекта указывают на области, которые стоит перепроверить, чтобы убедиться, что всё слито как ожидалось.
• Если изменение было ранее принято или отклонено во время слияния, оно не появится как diff при следующем слиянии тех же веток. Это ожидаемое поведение.

Например, вы сливаете Branch B в Branch A, и change C (существующее в Branch B) копируется в Branch A. Позже вы решаете отменить change C напрямую в Branch A. Теперь, если вы снова сливаете Branch B в Branch A, Git не отметит change C как различие. Это потому, что Git считает его уже слитым и больше не diff.

Лучшая практика: Держите истории веток короткими и простыми. После каждого слияния удаляйте слитую ветку, чтобы избежать ненужной сложности. Например, если вы сливаете Branch B в Branch A и позже хотите отменить или пересмотреть эти изменения, не возвращайтесь и не модифицируйте Branch B. Вместо этого создайте новую ветку (например, Branch C) из Branch A для ваших обновлений.

Этот подход предотвращает переплетение историй веток, избегает запутанного поведения слияния и обеспечивает чистые, отслеживаемые diff. Сосредоточение веток на конкретных задачах и их временный характер делает слияние более предсказуемым и управляемым.