# Apliteni git-flow

# Именование веток

  • master текущая стабильная ветка проекта. Часто именно она расскатана на production.
  • PROJ-XXXX называется по идентификатору задачи в Jira. Удаляем ветку сразу после слияния с веткой master или release-*.
  • release-x.x.x . Предназначены для аккумулирования фич к следующему релизу.

Системные ветки:

  • production ветка для CI. Пуш в эту ветку провоцирует деплой проекта через GitLab CI на production.
  • staging ветка для CI. Пуш в эту ветку провоцирует деплой через GitLab CI на стейджинговый сервер.

# Flows

Эти сценарии подразумевают, что:

  1. Автоматический деплой настроен на ветку production. Допустимо использование ветки master с ручным подтверждением деплоя в CI/CD.
  2. Наличие стабильной ветки и новые фичи изолируются и собираются в отдельной release- ветках.

# Hotfix - критический баг

  • Загружаем все теги проекта git pull --tags.
  • Находим последнюю версию минорную версию git tag -l | sort -V
  • Выгружаем по тегу git checkout x.x.x.x.
  • Подготовливаем релизную ветку с указанием следующей версии git checkout -b release-x.x.x.{x+1}.
  • Пушим релизную ветку git push origin release-x.x.x.{x+1}.
  • Создаем ветку, где будем коммитить хотфикс git checkout -b PROJ-XXXX.
  • Коммитим и пушим наш хотфикс git push origin PROJ-XXXX.
  • Оформляем сразу 2 Merge-Request, где в target указываем релизную ветку release-x.x.x.{x+1} и master.

# Создание фичи или фикс незначительного бага

  • Актуализируем ветку master: git pull origin master. Если новая фича зависит от другой, которая находится в ветке release-x.x.x, актализируем и используем эту ветку.
  • Создаем ветку по номеру Истории: git checkout -b PROJ-XXXX.
  • Коммитим, пушим в Gitlab: git push origin PROX-XXXX
  • Оформляем Merge-Request. В target указываем исходную ветку (master или release-x.x.x)

# Деплой релиза

  • Если проект использует версии, обновите номер версии приложения.
  • Пушим релизную ветку git push origin release-x.x.x:production.
  • После успешного деплоя, релизная ветка либо мержится с master, либо сразу удаляется. Дальше, если потребуется обратиться к этой версии, используем тег.

WARNING

Когда выкатываете хотфикс старой мажорной версии, убедитесь, что коммиты попали в текущие рабочие ветки.

# Оформление Merge-Request

# Проверяем наличие релизной ветки

У задач есть поле Version, где указана версия. Соотвественно, должна быть ветка release-{ВЕРСИЯ}. Если такой ветки нет, сделайте ее сами:

Ищим последний релиз

git pull -t
git tag -l | sort -rV | head -n 1 

Выгружаем

git checkout {ВЕРСИЯ}
git checkout -b release-ВЕРСИЯ

Пушим:

git push origin release-ВЕРСИЯ

# Создание MR в GitLab

  1. В Title пишем "Resolve идентификатор задачи" и краткое описание изменений (до 6 слов). Пример "Resolve GDBC-2244 подключение поставщика данных Aurocertg".
  2. В Assignees указываем всех, кто участвует в разработке проекта.
  3. Укажите в target целевую ветку.
  4. Ставьте галочку Delete source branch when merge request is accepted..
  5. Ставьте галочку Squash commits when merge request is accepted

Когда сливаем MR:

  1. Проверьте, что у проекта нет метки WIP: (Work in Progress) в заголовке.
  2. Обратите внимание на блок X/Y discussions resolved - это сколько было замечаний и сколько из них отмечены галочкой . Крайте важно, чтоб были отмечены все.
  3. Перед сливанием ставьте галочку "Remove source branch".

# Рекомендации к коммитам

  • Делайте коммиты чаще. Если комментарий содержит запятые или точки, то это признак того, что коммит у вас слишком большой. При сливании, мы включаем Squash commits, чтобы все коммиты ветки стали одним в после сливания.
  • Комментарий коммита начинается с номера задачи (Например, "GDBC-1233 add configuration file for postgres").
  • Комментарий пишется на английском. На грамматику не обращаем внимания, но всё-же стараемся писать аккуратно. Для простоты используйте Present Tense.

# Code Review

WARNING

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

# Рекомендации по Code Review

  • Начинайте день с проверки текущих MergeRequest'ов, где вы отмечены как Assignee. Если все ок, ставьте Approve. Список MR можно найти на странице To-Do List
  • При появлении уведомлений о новом MR, старайтесь при первой же возможности посмотреть его.
  • Задавайте вопросы. Например, вместо "Здесь используй библиотеку iconv", пишите "Почему бы не использовать библиотеку iconv?"
  • Ваш опыт отличается от остальных. Если вам что-то кажется очевидным, не полагайте, что и другому тоже.
  • Будьте вежливы. Если код не достигает нужного уровня качества, вежливо предлагайте улучшения и не забывайте заворачивать в форму вопроса.
  • Если вашу просьбу выполнили, ставьте маркировку Mark as Resolved на сообщении и всех ответах.
  • Если у вас нет вопросов, ставьте Approve или какой-нибудь emoji. Например, 👀.

WARNING

Если вас отметили как один из Assignee, вы обязаны любым способом отметиться в этом MR в течение 48 часов.

# Рефакторинг

  1. Составьте план и заведите историю.
  2. Убедитесь, что тесты покрывает участок, который вы собираетесь рефакторить. Если их мало, нужно сначала дописать.
  3. Следуйте плану и стремитесь держать тесты после каждого этапа зелеными. В процессе легко увлечься.

# Другие рекомендации

  • Используйте Git Subtree вместо Git Submodules.