Handbook

# 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 подключение поставщика данных Aurocertg".
  2. В Assignees указываем всех, кто участвует в разработке проекта.
  3. Укажите в target целевую ветку. Если разработка не ведется в отдельной ветки, оставляйте master.
  4. Ставьте галочку Delete source branch when merge request is accepted..
  5. Ставьте галочку Squash commits when merge request is accepted

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

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

# Code Review

Качественное code review позволяет сократить вероятность прохождения багов и поддерживать качество кода, поэтому участие в code review является приоритетной задачей для каждого.

Начинайте день с проверки текущих MergeRequest'ов, где вы отмечены как Assignee. Если все ок, ставьте Approve. Список MR можно найти на странице To-Do List

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

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

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

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

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

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

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

  • Делайте коммиты чаще. Если комментарий содержит запятые или точки, то это признак того, что коммит у вас слишком большой.
  • Используйте Git Subtree вместо Git Submodules.

← Code Style Guides →