Репозиторий предоставляет пример настройки CI для сборки и публикации в NPM монорепозиториев lerna на базе Github Actions.
Схема работы с репозиторием основана на классическом варианте Git Flow.
Последовательность работы при использовании модели Gitflow:
- Из master создается ветка develop.
- Из develop создаются ветки dev_*.
- Когда разработка новой функциональности завершена, она объединяется с веткой develop.
- Из develop создается ветка release/*.
- Когда ветка релиза готова, она объединяется с develop и master.
- Если в master обнаружена проблема, из нее создается ветка hotfix_*.
- Как только исправление на ветке hotfix завершено, она объединяется с develop и master.
Для определения версии используется семантическое версионирование.
- МАЖОРНАЯ версия, когда сделаны обратно несовместимые изменения API.
- МИНОРНАЯ версия, когда вы добавляете новую функциональность, не нарушая обратной совместимости.
- ПАТЧ-версия, когда вы делаете обратно совместимые исправления.
Формат commit-messages определяется стандартом conventional commits.
Commit’ы могут содержать следующие структурные элементы для сообщений пользователям вашей библиотеки:
- fix: commit типа fix исправляет ошибку (bug) в вашем коде (он соответствует PATCH в SemVer)
- feat: commit типа feat добавляет новую функцию (feature) в ваш код (он соответствует MINOR в SemVer).
- BREAKING CHANGE: commit, который содержит текст BREAKING CHANGE: в начале своего не обязательного тела сообщения (body) или в подвале (footer), добавляет изменения, нарушающие обратную совместимость вашего API (он соответствует MAJOR в SemVer). BREAKING CHANGE может быть частью commit’а любого типа.
- Другое: commit’ы с типами, которые отличаются от fix: и feat:, также разрешены. Например, @commitlint/config-conventional (основанный на The Angular convention) рекомендует: chore:, docs:, style:, refactor:, perf:, test:, и другие.
Почему нужно использовать Conventional Commits
- Автоматически генерируемый CHANGELOGs.
- Автоматическое определение семантической версии SemVer (на основе типов совершенных commit’ов).
- Коммуникация о характере изменений между товарищами по команде, общественностью и другими заинтересованными сторонами.
- Автоматически срабатываемый процесс сборки и публикации.
- Людям проще участвовать в вашем проекте, потому что им доступна более структурированная история коммитов
| branch | version | tag |
|---|---|---|
master |
из package.json |
latest |
release/<version> |
<version>-rc.<sha> |
next |
develop |
<version>-alpha/beta<sha> |
canary |
- При PUSH в master обновляется версия, создается тэг, и публикуется версия в NPM
- При создании ветки release/_ присваивается версия _-rc.*, публикация в NPM в ручном режиме по необходимости
- При PUSH/PULL_REQUEST в develop запускаются авто-тесты, создание альфа/бета версий и их публикация в ручном режиме по необходимости.
- version:release: обновление версий до релизных, создание тэгов и релизов github.
- version:pre-release: обновление версий до release candidate.
- version:pre-release:alpha: обновление версий до alpha.
- version:pre-release:beta: обновление версий до beta.
- publish:release: публикация релизной версии.
- publish:pre-release: публикация rc-версии.
- publish:pre-release:alpha: публикация alpha-версии.
- publish:pre-release:beta: публикация beta-версии.