Skip to content

Latest commit

 

History

History
31 lines (16 loc) · 6.18 KB

File metadata and controls

31 lines (16 loc) · 6.18 KB

Правила коммитов и сообщений

Формат заголовка

Заголовки коммитов следуют базовому формату <type>(<scope>): <subject> или более простому варианту без указания области <type>: <subject>. В качестве примеров можно привести сообщения вида fix(components): исправлено копирование ссылки в спойлере, docs(docs): обновлены правила для таблиц или chore: обновлены зависимости для разработки.

При составлении заголовка тип коммита записывается исключительно в нижнем регистре. Тип и тема сообщения не могут быть пустыми, а общая длина строки заголовка ограничивается 150 символами. При наличии тела коммита или сносок перед ними обязательно оставляется пустая строка. Если в коммите указывается несколько областей, они перечисляются через запятую с одним пробелом.

Требования к языку и стилю сообщений

Описание изменений составляется на русском языке, начинается с маленькой буквы и формулируется максимально кратко. Тема коммита пишется в форме достигнутого результата без точки на конце. Допускается использовать слова «добавлен», «исправлено», «обновлены», «удалены» или «вынесены». В сообщении запрещено упоминать прямые имена файлов или названия переменных.

Атомарность коммитов и разделение изменений

Изменения делятся на логические блоки, при этом каждый блок оформляется отдельным атомарным коммитом. Объединение разнородных правок в один общий коммит не допускается, их необходимо разделять строго по смыслу. Для разделения изменений в одном файле на несколько коммитов используются временные резервные файлы с расширением .bak, которые служат для безопасного разделения кода, не включаются в репозиторий и удаляются сразу после завершения работы.

Допустимые типы изменений

В проекте используются фиксированные типы изменений. Тип feat обозначает новую функциональность, fix применяется для исправления ошибок, а docs служит для редактирования документации. Для изменений в форматировании кода, не влияющих на логику, используется тип format, а рефакторинг без изменения функциональности обозначается как refactor. Рутинные задачи и обновление зависимостей описываются типом chore, изменения в статьях обозначаются как content, откат коммитов маркируется как revert, а слияние веток помечается типом merge.

Допустимые области изменений

В качестве областей применяются обозначения app для общих частей программы, components для элементов интерфейса, styles для оформления и слоев SCSS, hooks для React-хуков и utils для вспомогательных утилит. Изменения в контенте привязываются к областям aefaq, prfaq и psfaq в зависимости от целевого раздела в каталоге sections. Дополнительно используются области rules для правил, reg для регулярных выражений, links для адресов, docs для документации, config для файлов конфигурации, deps для внешних зависимостей, assets для медиаресурсов, scripts для скриптов автоматизации и символ * для глобальных изменений.

Исправление и отправка коммитов

Использование флага --no-verify при создании коммита запрещено. Точечные исправления в уже созданных локальных коммитах вносятся с помощью команды git commit --fixup с указанием хэша целевого коммита, что позволяет объединить их при последующем интерактивном перебазировании.

Автоматическая проверка

Проверка изменений и сообщений автоматизирована. Перед созданием коммита запускается проверка измененных файлов через инструменты линтинга, настроенные в системе управления хуками. При вводе сообщения выполняется валидация заголовка коммита с помощью утилиты commitlint.