Хотите ли вы следовать обычным коммитам и хотите ли вы применить правило, чтобы ваша команда также следовала ему? В этой статье вы узнаете, как применить правило Обычное комментирование перед фиксацией кода Angular или Nrwl.Nx Monorepo в GitHub. В наши дни все библиотеки с открытым исходным кодом, такие как платформа ngrx, начали следовать точным правилам форматирования сообщений коммитов git. Это приводит к более читаемым сообщениям, за которыми легко следить при просмотре истории проекта.

Что такое обычная фиксация?

Спецификация Conventional Commits — это облегченное соглашение поверх сообщений фиксации. Он предоставляет простой набор правил для создания явной истории коммитов; что упрощает написание автоматизированных инструментов поверх. Это соглашение согласуется с SemVer (семантическое управление версиями), описывая функции, исправления и критические изменения, сделанные в сообщениях фиксации.

Почему обычная фиксация?

Мы будем использовать спецификацию Conventional Commits. Так что поверх него будет легко писать автоматизированные инструменты. Например, если вы следуете обычным коммитам, вы можете написать некоторую автоматизацию для

  • Увеличить версию файла package.json на основе формата сообщения фиксации.
  • Вы можете создать журнал изменений автоматически.

Если вы уверены, продолжайте читать, чтобы настроить это правило в своем проекте angular или любом другом проекте node.js.

Примеры обычного формата сообщений

Сообщение фиксации с областью действия и без текстаdocs(readme): correct spelling of package

Сообщение фиксации с областью действия, описанием и нижним колонтитулом о критических изменениях

feat(logger): need to depend on websocket library BREAKING CHANGE: the api parameters changed

Узнайте подробнее здесь.

Обычный формат сообщения фиксации

Мы будем использовать обычную фиксацию для обеспечения дисциплины.

Сообщение фиксации должно быть структурировано следующим образом:

Заголовок является обязательным, а область заголовка не является обязательной. Любая строка сообщения коммита не может быть длиннее 120 символов! Это упрощает чтение сообщения на GitHub, а также в различных инструментах git.

Обычный тип фиксации

Тип Должен быть одним из следующих:

  • сборка: изменения, влияющие на систему сборки или внешние зависимости (примеры областей: webpack, karma, npm).
  • ci: изменения в наших файлах конфигурации и скриптах CI (примеры областей действия: azuredevops.yaml, Travis, Circle, BrowserStack, SauceLabs)
  • документы: изменяется только документация.
  • feat: новая функция
  • fix: исправление ошибки
  • perf: изменение кода, повышающее производительность.
  • рефакторинг: изменение кода, которое не устраняет ошибку и не добавляет новую функцию.
  • стиль: изменения, не влияющие на смысл кода (пробелы, форматирование, отсутствие точек с запятой и т. д.)
  • тест: добавление отсутствующих тестов или исправление существующих тестов.

Обычная область фиксации

Областью действия должно быть имя затронутого пакета npm (как его воспринимает человек, читающий журнал изменений, созданный из сообщений фиксации. Например, если у вас есть проект, в котором у вас есть публикуемые библиотеки и приложения. Тогда вы можете использовать их имена проектов.

Приложения: администратор, клиент, панель инструментов. Библиотека: регистратор, макет, обмен сообщениями.

Ниже приведен список поддерживаемых областей:

Обычный предмет фиксации

Тема содержит краткое описание изменения и несколько советов по тексту темы:

  • используйте повелительное наклонение, настоящее время: «изменить», а не «изменить» или «изменить»
  • не делайте первую букву заглавной
  • без точки (.) в конце

Традиционный орган фиксации

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

Нижний колонтитул должен содержать любую информацию о критических изменениях, а также является местом для ссылки на проблемы GitHub, которые закрывает этот коммит.

Критические изменения должны начинаться со слова BREAKING CHANGE:` с пробелом или двумя символами новой строки. Затем для этого используется остальная часть сообщения фиксации.

Пример:

feat(scope): commit message BREAKING CHANGES: Describe breaking changes here BEFORE: Previous code example here AFTER: New code example here

Давайте узнаем, как мы можем автоматизировать эти правила в нашем собственном проекте, чтобы ни один член команды не мог их нарушить.

Пакет Commitlint Node

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

Мы также будем использовать husky для запуска правил линтинга перед фиксацией.

Запустите приведенный ниже скрипт, чтобы установить commitlint и хаски.

npm i -D husky @commitlint/cli @commitlint/config-conventional

Добавление правил в package.json

Что здесь произойдет, так это то, что каждый раз, когда предпринимается попытка коммита, он будет анализироваться на основе обычных правил сообщения коммита. Разработчик получит сообщение об ошибке, если они отклонятся. Поначалу это болезненно, но через некоторое время это становится второй натурой!

Тестирование обычных правил коммитов

Добавьте комментарий adding commit rules и попробуйте зафиксировать

Обратите внимание, что вы видите ошибку.

Совершить ошибку

Давайте исправим наш комментарий в соответствии с обычным правилом фиксации. Измените комментарий, как показано ниже, и зафиксируйте

build: added new script for linting

Теперь вы должны быть в состоянии зафиксировать свой код.

Обратите внимание, что мы можем успешно зафиксировать и отправить наш код.

Вывод

Теперь вы узнаете, как можно использовать обычные коммиты и применять это правило в своем проекте. В моей следующей статье я объясню, как вы можете применить некоторую автоматизацию в этом проекте. Например, автоматическое изменение версий package.json, создание журнала изменений и т. д. Так что следите за обновлениями.

Станьте полноценным разработчиком 💻

Если вы хотите стать разработчиком полного стека и развивать свою карьеру в качестве нового разработчика программного обеспечения или ведущего разработчика/архитектора. Рассмотрите возможность подписки на наши обучающие программы полного стека. У нас есть планы ежемесячного членства с полным доступом, и вы получите неограниченный доступ ко всем нашим видеокурсам, слайдам, исходному коду и ежемесячным видеозвонкам.

  • Пожалуйста, подпишитесь на План All-Access Membership PRO, ​​чтобы получить доступ к текущим и будущим курсам angular, node.js и связанным с ними курсам.
  • Пожалуйста, подпишитесь на План All-Access Membership ELITE, чтобы получить все от плана PRO. Кроме того, вы получите доступ к ежемесячному видеозвонку с вопросами и ответами в прямом эфире с Рупешем, где сможете задать сомнения/вопросы и получить дополнительную помощь, советы и рекомендации.

Вас ждет светлое будущее, поэтому посетите сегодня FullstackMaster и позвольте мне помочь вам попасть в компанию по разработке программного обеспечения вашей мечты в качестве разработчика, архитектора или ведущего инженера.

💖 Скажи мне 👋!

Первоначально опубликовано на https://rupeshtiwari.github.io 8 февраля 2021 г.