Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.
22. Стратегии ветвления в Git
«Опишите стратегию ветвления Git, которую вы использовали в своих проектах, и как она помогает эффективно управлять циклами разработки и выпуска?»
Хороший ответ
Одна из эффективных стратегий ветвления Git — стратегия Git Flow. Согласно этой стратегии, работа организуется вокруг двух ветвей с бесконечным временем жизни:
- главная ветка (main), в которой исходный код HEAD всегда отражает состояние, готовое к использованию в продакшене.
- ветка develop служит интеграционной ветвью для новых функций. Она всегда отражает состояние с последними внесёнными изменениями для следующего релиза.
Дополнительные ветки, используемые в Git Flow:
- Ветки функций (Feature branches) – ответвляются от develop и сливаются обратно в develop. Каждая feature-ветка используется для разработки новой функции для будущего релиза. Обычно они создаются для каждой новой функции.
- Ветки релизов (Release branches) - ответвляются от develop и сливаются в develop и main. Используются для подготовки к новому релизу. Позволяют вносить незначительные исправления ошибок и подготавливать метаданные для релиза (номер версии, дату сборки и т.д.).
- Ветки исправлений (Hotfix branches) - ответвляются от main и сливаются в develop и main. Используются для быстрого обновления производственных релизов.
Такой структурированный подход позволяет одновременно осуществлять множество видов разработки, не мешая друг другу, поддерживает параллельную разработку функций, подготовку к будущим релизам и оперативное устранение проблем, влияющих на производственную среду.
Вот как можно использовать эту стратегию на практике:
# Создание ветки для функции
git checkout -b feature/new-cool-feature develop
# Завершение работы над функцией и слияние
git checkout develop
git merge feature/new-cool-feature
git branch -d feature/new-cool-feature
# Подготовка релиза
git checkout -b release/1.2.0 develop
#Специфичная для релиза метаинформация
git checkout master
git merge release/1.2.0
git tag -a 1.2.0
# Патч бага в продакшене
git checkout -b hotfix/urgent-fix master
#Исправление бага
git checkout master
git merge hotfix/urgent-fix
git tag -a 1.2.1
git checkout develop
git merge hotfix/urgent-fix
git branch -d hotfix/urgent-fix
Эта стратегия особенно полезна для поддержания контроля над разработкой и релизами, обеспечивая надёжную доставку ПО.
Часто встречающийся плохой ответ
«Мы использовали одну ветку для всего, потому что это проще и легче в управлении. После тестирования кода мы делали коммиты напрямую в ветку main, не усложняя систему несколькими ветками.»
Почему это неправильно:
- Риск нестабильности: коммиты напрямую в main увеличивают риск внедрения нестабильного кода в продакшн. Это может привести к серьёзным проблемам с развёртыванием и эксплуатацией.
- Отсутствие изоляции для новых функций: такой подход игнорирует преимущества изоляции новой работы по разработке в ветках функций, что минимизирует влияние на основную кодовую базу и другую текущую работу.
- Неэффективность в обработке релизов и исправлений: без выделенных веток для релизов и исправлений становится сложно управлять различными версиями и исправлять проблемы, не влияя на основной рабочий процесс разработки.
Обычно эта ошибка возникает из-за недостатка опыта работы с совместными проектами значительной сложности или непонимания важности структурированных рабочих процессов для поддержания качества и стабильности кода. Такой подход может привести к значительным проблемам масштабирования процесса разработки и управления несколькими одновременными инициативами.
Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md