Продолжая тему управления проектами в IT-сфере, хочу затронуть один важный аспект — ветвление (branching) в системах контроля версий, таких как Git.
В Телеграм есть канал "Самоучки IT(Управление проектами)" https://t.me/+NfVrLMxdKS0yNDNi где регулярно пополняется материал по всем этим вопросам.
Git Flow - это одна из самых популярных методик работы с гитом, которая предоставляет огромные возможности по работе с ветками, коммитами, просмотру истории, откатам, черепицам и многим другим вещам. Однако у гита есть одна фундаментальная проблема — отсутствие стандартной методики, по которой можно было бы вести проекты. Поэтому и появилось множество методических подходов, одним из которых является Git Flow
Git Flow - это методика, которая позволяет использовать функциональные ветки для внедрения фич и набор основных веток, которые позволяют делать релизы или трясти наш успех. Эта методика хорошо подходит для проектов, жизненный цикл которых составляет один или две недели. Я лично использую Git Flow в 95% своих проектов, которые я веду вместе с командами, и могу с уверенностью сказать, что она очень хорошо подходит для Agale методологий, таких как, Scrum, где спринты длительностью одна или две недели.
Давайте теперь разберемся, что стоит за Git Flow и как по нему работать. Начнем с того, что Git Flow - это методика, которая предоставляет функциональные ветки для внедрения фич и набор основных веток, которые позволяют делать релизы или трясти наш успех. Все начинается с двух основных веток: Main (или Master) и Develop.
На вершине ветки Main создаются теги, которые служат для маркировки определенных моментов в истории разработки проекта. Эти теги используются для сборки проекта, выпуска САСД и других процессов, связанных с релизами. Таким образом, ветка Main остается стабильной и содержит только версии проекта, готовые к развертыванию в продакшен…
Develop - это рабочая ветка, куда, если вдруг что-то мы принимаем, оно попадает в Develop. Это некоторые отрывочные коды, которые в результате попадают у нас в Develop, а затем уже через какой-то процесс попадают в продакшен. Ветка Develop также должна быть всегда стабильной, поэтому напрямую в нее делать коммиты также нельзя.
Далее, когда мы хотим внедрить какую-то фичу, мы создаем отдельную ветку от Develop, которую называем Фичер веткой. Фичер ветка — это ветка, которую берут от Develop, когда приходит и хочет внедрить какую-то фичу, разработчик. В этой ветке работы он может ковать сколько угодно комитов, всё что угодно делать и в результате, получать какой-то финальную работающую фичу или исправленный баг, если мы говорим о баг.
Когда фича готова, ее нужно влить в Develop. Для этого мы создаем Pull Request (PR)и просим кого-нибудь из команды проверить наш код. Этот процесс называется Код Ревью. Код Ревью — это очень важный процесс, который позволяет нам доставлять качественный код в продакшен. Поэтому без Код Ревью мы не можем влить нашу фичу в Develop.
Когда фича прошла Код Ревью и была влита в Develop, мы можем начать готовиться к релизу. Для этого мы создаем отдельную ветку от Develop, которую называем Релизной веткой. Релизная ветка — это ветка, в которую мы вливаем все фичи, которые должны быть в следующем релизе. Эта ветка обычно тестируется ручными тестировщиками, а также запускаются все автоматические тесты.
Когда релиз готов, мы его вливаем в Мэйн и создаем тег с номером релиза. После этого мы также вливаем релиз в Develop, чтобы все фиксы, которые были сделаны в релизной ветке, попали в наш основную рабочую ветку.
Иногда может случиться так, что в продакшене обнаружилась критическая ошибка, которую нужно исправить срочно. В этом случае мы создаем отдельную ветку от Main, которую называем Hotfix веткой. Hotfix ветка — это ветка, в которую мы вносим изменения, которые необходимо срочно исправить в продакшене. Когда изменения готовы, мы их тестируем и вливаем в Main и Develop. После этого мы также создаем новый релиз, который содержит наш Hotfix.
Итак, мы рассмотрели основные ветки и процессы, которые используются в Git Flow. Давайте теперь рассмотрим некоторые практические примеры использования Git Flow.
Пример 1. Внедрение новой фичи.
Предположим, нам нужно внедрить новую фичу в нашем проекте. Для этого мы выполняем следующие шаги:
-Создаем новую ветку от Develop, например: git checkout -b feature/my-new-feature develop
-Делаем необходимые изменения в коде и комитим их: git add.; git commit -m "Add my new feature"
-Отправляем наши изменения на удаленный репозиторий: git push origin feature/my-new-feature
-Создаем Pull Request в Develop.
-Просим кого-нибудь из команды проверить наш код и дать комментарии.
-Вносим необходимые изменения на основе комментариев и отправляем их в Pull Request.
-Когда наш код прошел Код Ревью, мы вливаем его в Develop: git checkout develop; git pull; git merge feature/my-new-feature; git push origin develop
-Удаляем нашу Feature ветку: git branch -d feature/my-new-feature
Пример 2. Исправление критической ошибки в продакшене.
Предположим, в нашем проекте в продакшене обнаружилась критическая ошибка, которую нужно исправить срочно. Для этого мы выполняем следующие шаги:
-Создаем новую ветку от Main, например: git checkout -b hotfix/critical-bug-fix master
-Делаем необходимые изменения в коде и комитим их: git add.; git commit -m "Fix critical bug"
-Отправляем наши изменения на удаленный репозиторий: git push origin hotfix/critical-bug-fix
-Создаем Pull Request в Main.
-Просим кого-нибудь из команды проверить наш код и дать комментарии.
-Вносим необходимые изменения на основе комментариев и отправляем их в Pull Request.
-Когда наш код прошел Код Ревью, мы вливаем его в Main : git checkout master; git pull; git merge hotfix/critical-bug-fix; git push origin master
-Создаем новый тег с номером релиза: git tag -a v1.1.1 -m "Hotfix release"
-Вливаем наш hotfix в Develop : git checkout develop; git pull; git merge hotfix/critical-bug-fix; git push origin develop
-Удаляем нашу hotfix ветку: git branch -d hotfix/critical-bug-fix
Итак, мы рассмотрели основные ветки и процессы, которые используются в Git Flow, а также практические примеры их использования. Git Flow - это очень мощная и гибкая методика, которая позволяет нам эффективно работать с гитом и контролировать процесс разработки. Если вы еще не используете Git Flow в своих проектах, я рекомендую вам его попробовать. Вы не пожалеете!
Ну и в конце небольшое примечание. Git Flow - это не догма, а всего лишь набор рекомендаций, которые можно изменять под свои нужды. Если какой-то процесс не подходит вашей команде, вы всегда можете его изменить или вообще не использовать. Главное — чтобы процесс работы был понятен всем участникам команды и не мешал эффективной разработке. Пользуйтесь на здоровье, а подробности изучайте в канале "Самоучки IT(Управление проектами) https://t.me/+NfVrLMxdKS0yNDNi - там много годного материала и обсуждения!