Работа с Git

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

Имена веток формируются по шаблону <issue-code>/<short-descr> - например qg-81/create-client. Можно заводить по несколько веток на одну задачу.

Сообщения коммитов

Используется соглашение, вдохновлённое Conventional Commits.

Используемые типы коммитов:

  1. build: Изменения сборки (в том числе зависимостей) проекта
  2. chore: Мелкие непонятные изменения (исравление проблем после мёржа/ребейза, забытые изменения и т.п.)
  3. ci: Изменения в скриптах CI
  4. docs: Изменения только в документации
  5. env: Изменения в дев-окружении проекта (добавление/исправление ран-конфигов, скриптов, конфигов тулов, локальный докер-файлов и т.п.)
  6. feat: Изменения добавляющие новую функциональность
  7. fix: Изменения исправляющие баг
  8. ops: Изменения связанные с эксплуатацией проекта (дополнительные параметры конфигурации, логи, метрики, мониторинг и т.п.)
  9. perf: Изменения улучшающие прозводительность
  10. refactor: Рефакторинг
  11. review: Изменения по требованию ревьювера
  12. style: Мелкие стилистические изменения (форматирование)
  13. test: Изменения затрагивающие только тесты

Коммиты пишутся на грамотном русском языке.

В отличие от Conventional Commits, заголовок сообщения должен содержать после типа коммита через "/" номер основной задачи в рамках которых он выполнен.

Пример сообщения без тела:

feat/qg-115: Реализован метод POST /logout

Тело опционально, но его стоит написать, если коммит содержит какие-то неочевидные/необычные решения или вызван какими-то неочевидными/необычными обстоятельствами или мотивами.

Заголовки ПР-ов должны соответствовать тем же правилам, что и сообщения коммитов

Так как мы применяем squash при мёрже и заголовки МР-ов превращаются в сообщения коммитов.

МРы не должны содержать в себе мёрж-коммитов

Для этого при pull-е изменений из ремоута надо делать либо hard reset, если локально нет важных изменений, либо пулл с ребейзом

Коммиты не должны содержать нерелевантных изменений