Swift Interview. Средний уровень. Система контроля версий.

Какие gitFlow вы использовали?

Отсутствие ответа на этот вопрос будет вам большим минусом и покажет ваше полное незнание процессов командной разработки. Что не допустимо для миддла и выше.

Можно рассказать про последний проект. При указании конкретной модели, лучше сделать краткое описание (примерное для классическое gitFlow): «Мы создавали feature-ветки от develop. Когда фича готова, создавался Pull Request (или Merge Request) в develop. После код-ревью и прохождения всех проверок (Unit-тесты, линтер) мы мерджили ветку. Перед релизом создавалась ветка release/*, где мы занимались только багфиксингом. Готовый релиз мерджился в main (master) и обратно в develop». Так же можно добавить про CI/CD.

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

Вот краткая сводка:

Основные модели Git Flow — это Gitflow (строгая структура, ветки master/develop), GitHub Flow (простая, только main и фичи, GitLab Flow (гибрид с окружениями) и Trunk-based Development (единственная долгоживущая ветка с максимально частой интеграцией). Gitflow подходит для классических релизов, GitHub Flow — для непрерывной доставки (CI/CD), GitLab Flow — для промежуточных вариантов, , а Trunk-based — для максимальной скорости интеграции.

Сравнение популярных Git Flow моделей:

Gitflow (Классический):

• Структура: Две главные ветки (master, develop) + вспомогательные (feature, release, hotfix).
• Плюсы: Четкая структура, идеален для параллельной разработки, релизных циклов и поддержки старых версий.
• Минусы: Высокая сложность, долгая жизнь веток, частые конфликты слияния.
• Когда использовать: Сложные продукты, редкие релизы (версионность).

GitHub Flow (Легкий):

• Структура: Только main ветка и функциональные ветки (feature branches).
• Плюсы: Простота, идеально для частых релизов и Continuous Delivery, подходит маленьким командам.
• Минусы: Не подходит для поддержки нескольких версий продукта одновременно.
• Когда использовать: SaaS-проекты, веб-разработка, небольшие команды.

GitLab Flow (Гибридный):

• Структура: Работает напрямую с основной веткой, поддерживает ветки окружений (например, preproduction, production).
• Плюсы: Объединяет простоту GitHub Flow с возможностью структурированного тестирования, решает проблемы с релизными циклами.
• Минусы: Сложнее, чем GitHub Flow, требует четкой автоматизации CI/CD.
• Когда использовать: Команды, практикующие непрерывную интеграцию (CI), которым нужно разделять стадии тестирования.

Trunk-based Development (Продвинутый):

• Структура: Единственная долгоживущая ветка (trunk/main) и очень короткоживущие фича-ветки (до 1-2 дней).
• Плюсы: Минимум конфликтов слияния, максимальная скорость интеграции, мгновенное обнаружение ошибок, идеально для CI/CD и фича-тогглов.
• Минусы: Требует высокой дисциплины команды, отличного покрытия тестами и обязательного использования фича-тогглов для скрытия неготового функционала.
• Когда использовать: Высоконагруженные команды с непрерывной поставкой, проекты с развитой инфраструктурой CI/CD, где важна скорость выкатки фич

Ключевые отличия в подходе:

Gitflow использует ветку develop для интеграции, в то время как GitHub/GitLab Flow работают непосредственно с основной веткой (master/main). Trunk-based Development также работает напрямую с основной веткой, но требует еще более частой интеграции — несколько раз в день.

Gitflow создает крупные коммиты перед релизом, в то время как GitHub Flow, GitLab Flow и Trunk-based Development подразумевают мелкие, частые изменения. При этом Trunk-based Development доводит этот подход до максимума, используя очень короткоживущие ветки и фича-тогглы для скрытия неготового функционала.

Более подробно про Gitflow 👇👇👇
Более подробно про GitLab 👇👇👇
Более подробно про TBD 👇👇👇

Ссылка на канал в Телеграмме👇👇👇