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. Следуйте плану и стремитесь держать тесты после каждого этапа зелеными. В процессе легко увлечься.