Алгоритм

1. Новая таска размещается на канбан доске в GitLab Issue Boards (колонка Open)
2. В телеграме таска распределяется единственному исполнителю
3. Исполнитель создаёт в репозитории новую ветку на базе develop (например, feature/rabbitmq)
4. Исполнитель пушит в эту ветку коммиты
5. По завершении задачи, исполнитель открывает MR из этой ветки в исходную (develop)
6. Напарник проводит код-ревью MR и в результате либо построчно комментирует недочёты в коде, либо сразу мержит одну ветку в другую
7. При наличии недочётов, исполнитель пушит в ветку новые коммиты, исправляющие ситуацию
8. Повторное код-ревью
9. Мёрж одной ветки в другую (закрытие MR)

Конвенции

Конвенции регламентируют процесс разработки, ограничивая участников правилами написания кода, названия коммитов, веток, MR-ов и пр. Соблюдаемые в каждом репозитории конвенции выбираются командой, работающей над этим репозиторием (соответственно, от репозитория к репозиторию конвенции могут меняться).

Коммиты

Conventional commits

Конвенция

тип(скоуп): описание

тип: описание

Тип коммита классифицирует характер внесённых изменений. Ограничивает поведение разработчика в рамках одного коммита: например, нельзя одновременно пофиксить баг fix и добавить новую фичу feat.

Скоуп описывает область проекта, затронутую коммитом. При наличии ограничивает поведение разработчика в рамках одного коммита: например, нельзя одновременно добавить код в несвязанные (не поддающиеся обобщению) скоупы persistence (DAL) и api (HTTP контроллеры). Где это возможно, предпочтение отдаётся абстрактной продуктовой терминологии, а не конкретной технической: users вместо UserUpdateCommand, configuration вместо app settings. Сокращения не приветствуются: localization вместо local, configuration вместо config. Допускается отсутствие скоупа. Соблюдение единого нейминга в рамках одного репозитория необходимо.

Описание — короткое и ёмкое, в настоящем времени. Допускаются перечисления: add ru-RU and en-US locales, fix memory leak by migrating to NewtonsoftJSON, describe services and DTOs. Английский язык — везде, где возможно.

Типы коммитов

• feat — добавление новой функциональности, влияющее на взаимодействие клиента с сервисом (триггерит minor релиз)
• fix — изменение логики работы кода для устранения бага/ошибки, влияющее на взаимодействие клиента с сервисом (триггерит patch релиз)
• perf — оптимизация потребления ресурсов (триггерит patch релиз)
• refactor — рефакторинг, изменения формы кода, не влияющие на логику его работы
• chore — регулярная поддержка кодовой базы с точки зрения окружения и инфраструктуры (например, обновление библиотек, изменение процесса сборки), не затрагивающая кодовую базу самого сервиса и тестов
• tests — покрытие тестами или их исправление без внесения изменений в кодовую базу самого сервиса
• ci — изменение конфигураций CI/CD
• revert — откат коммита (см. git revert)

Использование других типов не допускается.

Примеры

feat(users): add registration use-case

fix(configuration): replace KAFKA_BOOTSTRAP_HOST with KAFKA_BOOTSTRAP_SERVER

fix(parsing): eliminate JSON parser memory leak

refactor(persistence): replace data annotations with separate entity configuration classes

refactor(api): decorate controllers with OpenAPI documentation

refactor: apply Microsoft code style guidelines

chore(dependencies): update NuGet packages to the latest versions

revert: replace data annotations with separate entity configuration classes