GIT FLOW

GIT FLOW

Основные ветки проектов:

Develop: основная рабочая ветвь. Все новые ветки создаём из неё. Она содержит код, готовый для тестирования.

Main: содержит стабильный протестированный код. Код в этой ветке всегда готов к деплою на продакшн.

Нельзя делать коммиты напрямую в develop и main, только в свои фичи-ветки (feature branches).

Ветки и таски

• На каждую задачу создается отдельная ветка. Вся работа над задачей ведется в этой ветке.

• Формат имени ветки: (фича feature/name, фикс fix/name) и одно или несколько английских слов, описывающих задачу, через дефисы.

• Смердженные ветки удаляются после MR , но только когда все изменения приняты, проверены и внесены правки.

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

• Каждый MR должен быть рабочей версией проекта, которую можно запустить или залить на сервер.

• Можно параллельно делать несколько задач и сдавать их сразу несколько, но тогда нужно вносить изменения по одному из MR в каждую ветку из активных задач

Как писать коммиты

4 вида коммитов

[*] - рефакторинг\изменения логики, исправление багов

[+] - добавление фичи

[-] - удаление файла\фичи

[~] - правки, не влияющие на логику проекта (например, линтеры)

В каждом коммите следует писать Reason(R:) и fixed by(FB:)

R: причина коммита, что этот коммит изменил

FB: как исправили, каким способом решили проблему

Пример правильного коммита

Пример 1:

[~] правки форматирования и lint

R: код был не оптимальным и плохо форматированным

FB: использовал eslint и prettier

Как оформлять MR

Заголовок

В заголовке следует назвать реализованный функционал (что было добавлено, кратко). В самом начале надо указать BUGFIX (в случае, если были исправления багов) или FEAT (добавление нового функционала). Если MR ещё не готов к просмотру, следует пометить его как черновик (Draft).

Описание MR

В описании есть два основных пункта:

• Что было сделано (краткое описание основного функционала приложения)

• Отчет о тестировании (описание тестирования конкретного функционала)

Reviewer

Требуется указать ревьюера

Объем изменений

Изменений в каждом mr должно быть не более 500 строк (добавление и удаление в сумме).

Запрос на слияние

• Вносим необходимые изменения в свою ветку • Создаем merge request своей ветки в develop

• Заполняем описание по форме

• Запрашиваем ревью (в т.ч. отписываемся в группе фронтов)

• Если всё ок (пайплайн прошёл/ревью) — merge request одобряется и сливается в develop

Код ревью

Для начала сами проверяем свою задачу по документации, потом отдаём её на ревью. Как только в группе фронтов появляется MR, заходим в этот MR, проверяем по документации. Если есть комментарии, то оставляем их под MR. Если есть ошибки - пишем комментарии. Если всё хорошо, нажимаем кнопку Approve. (MR должно проверить минимум 2 человека).

Релиз В конце цикла разработки develop сливается в main и деплоится на сервер