# Apliteni git-flow

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

• master ветка, которая всегда готова к деплою. От нее делаем хотфиксы.
• PROJ-NNN называется по идентификатору задачи в Jira. Удаляем сразу после вливания в master или релизную ветку.
• release-x.x . Предназначены для аккумулирования фич к следующему релизу.

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

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

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

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

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

1. В Title пишем "Resolve идентификатор задачи" и краткое описание изменений (до 6 слов). Пример "Resolve GDBC-2244 подключение поставщика данных XbotCeretg".
2. В Assignees указываем всех, кто участвует в разработке проекта.
3. В Target указывается ветка куда будет происходить вливание и отмечайте галочку 'Delete source branch'.

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

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

# Именование git-репозиториев

• Нижний регистр.
• Разделитель "-".

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

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