Перейти к основному содержанию
`Ctrl`+`K`

# Global GitFlow

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

Внимание

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

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

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

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

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

В основные ветки запрещены прямые пуши. Все изменения сливаются через `Merge Request` и проходят `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` в ветку `main`. `MR` должен содержать исчерпывающее описание внесённых изменений, включая:

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

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

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

- ссылки на `MR`.

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

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

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

## Заключение

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

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

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

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

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