# 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, либо сразу удаляется. Дальше, если потребуется обратиться к этой версии, используем тег.

# Оформление 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

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

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

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

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

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

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