Global GitFlow

Global GitFlow#

Global GitFlow — модель ветвления Git. Данная модель регламентирует процесс разработки, устанавливая четкие правила создания и именования веток, а также процедуры слияния и создания merge request’ов (MR).

Внимание

Настоящее руководство применяется исключительно для модулей gtk и btk.

Рекомендации по настройке окружения#

Для обеспечения эффективной работы рекомендуется использовать редактор VS Code в качестве стандартного git-редактора. Установка производится следующей командой:

git config --global core.editor "code --wait"

Изображение ветвления

Основные ветки#

В основные ветки запрещены прямые пуши. Все изменения сливаются через Merge Request’ы (MR) и проходят Code Review. Все новые изменения или доработки существующего функционала сначала отправляются в main ветку, после чего, если необходимо перенести их в последующие ветки, создаются ветки переноса, куда черри-пикаются изменения. Уже от этих веток изменения сливаются в release-candidate и в release.

  • release — ветка production-окружения. Содержит исключительно стабильный код, соответствующий выпущенным версиям продукта. Обновляется только через слияние ветки release-candidate или черри-пиками хотфиксов.

  • release-candidate — ветка стабилизации релиза. Формируется как ответвление от main. Подвергается недельному циклу тестирования и исправлению обнаруженных ошибок. После чего изменения сливаются в ветку release.

  • main — основная ветка разработки. Используется для интеграции нового функционала. Все feature-ветки создаются от main и в нее же сливаются посредством MR.

Вспомогательные ветки#

  • feature — ветка для разработки нового функционала в рамках конкретной задачи. Создается исключительно от ветки main и в нее же сливается посредством MR.

  • hotfix — ветка для экстренных исправлений. Создается от ветки main, в нее же сливается, после чего изменения переносятся в ветки release-candidate и (или) release, посредством черри-пиков.

  • pick — ветки переноса изменений между ветками. При необходимости переноса изменений между ветками, именно в данную ветку черри-пикаются изменения и от неё же создаётся MR.

Совет

Правила наименования веток

Тестирование веток#

  1. main — основная ветка разработки тестируется на астре smtu-test.

  2. release-candidate — кандидат на релиз, тестируется на астре pgDev.

  3. release — стабильная версия, не тестируется, так как с неё выпускаются релизы.

Процесс выпуска релизов#

Выпуск релизов происходит еженедельно, каждый понедельник в 16:00. Сначала ветка release-candidate сливается в release, после чего актуализируется посредством слияния в неё ветки main. После слияния выпускаются релизы модулей по ветке release.

Организация разработки#

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

Для новых функциональных изменений создаётся ветка типа feature, для критических исправлений — hotfix. Название ветки должно однозначно идентифицировать задачу, включая её идентификатор в системе учёта задач.

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

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

Совет

Правила наименования коммитов

После завершения всех изменений по задаче необходимо создать Merge Request (MR) в ветку main. MR должен содержать исчерпывающее описание внесённых изменений, включая:

  • цель и мотивацию изменений;

  • описание реализации;

  • номер задачи;

  • ссылки на MR.

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

После успешного слияния MR с веткой main может потребоваться перенос изменений в другие ветки (например, в release-candidate или release). Для этого используются специальные pick-ветки, создаваемые на основе целевой ветки. Изменения переносятся черри-пиками, которые позволяют выборочно применять коммиты из одной ветки в другую.

При переносе изменений в ветку release обязательно нужно также перенести их в соответствующую ветку release-candidate. Для каждого переноса создаётся отдельный MR с указанием исходного MR в main. Это обеспечивает прослеживаемость изменений между ветками.

Заключение#

Соблюдение описанной модели ветвления обеспечивает:

  • Стабильность production-окружения.

  • Контролируемый процесс разработки.

  • Эффективное управление релизами.

  • Минимизацию конфликтов при слиянии кода.

Содержание