Git Flow. Разделяй и властвуй: Сила ветвления в разработке ПО⁠⁠

Продолжая тему управления проектами в 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  - там  много годного материала и обсуждения!