В дополнении к прошлому посту хочу добавить, что также будет использоваться технология Git, хорошо известная всем система контроля версий, созданная для хранения кодовых баз, истории, организации и многое другое.
Почему я вообще вспомнил про Git? Наткнулся на статью в интернете, в которой рассказывается о конвенции коммитов и решил закрепить для себя. Она создана для решения одной известной проблемы: описание коммитов. Довольно часто новички сильно не задумываются о названии и описании коммитов и пишут в них бессмыслицу. Конвенция же решает эту проблему. Она ввела новый стандарт.
Основные моменты:
- Каждый коммит имеет такую структуру: [optional scope]: description
[optional body]
[optional footer]
-
Основные типы: 1. fix - используется, если коммит является фиксом бага 2. feat - используется, если коммит является внедрением новой feature 3. chore - используется, если изменения коммита не влияют на функциональную часть приложения, также не является фиксом бага, например обновление зависимостей, рефакторинг (без изменения функционала) 4. build - используется, если изменения затрагивают сборку проекта 5. docs - используется, если внедряется/изменяется документация проекта 6. test - используется, если коммит добавил/изменил элементы тестирования
-
Если в коммите произошли критические изменения, после типа ставится !, например: chore!: upgrade node version to 18.1.0
-
К типу можно добавлять контекст изменения: fix(order-page): disable buy button without auth
-
description представляет из себя краткое содержание изменений кода: feat: add table of characteristics for item page
Про body & footer можно почитать в самой статье, что рекомендую. type & description уже имеют достаточный вес, чтобы удобнее использовать историю коммитов.
