предисловие
Недавно по прихоти я планирую использовать vue3+ts, чтобы написать h5 для запоминания стихов (чтобы удовлетворить мою собственную привычку заучивать стихи). Если рабочий хочет хорошо работать, он должен сначала заточить свои инструменты. Сначала поставь полку! Хотя это проект, написанный мной, должны быть некоторые спецификации разработки! При создании спецификаций коммитов и автоматической генерации журналов изменений я наступил на бесчисленное количество ям, потому что хотел отправить формат коммита в начале смайликов! ! ! Так что напишите эту статью, чтобы почтить память ~ О! Нет~ Это краткое изложение, которым я хочу поделиться со всеми людьми вокруг меня, которые хотят ступить на яму~ Ладно! Без лишних слов, давайте начнем мое шоу~😝
Спецификация фиксации
Прежде всего, стандартизированная информация о коммите позволяет людям с первого взгляда четко определить, к какому типу, объему модификации и конкретным изменениям относится коммит, что улучшает совместную работу команды. Также нам удобно находить баги в будущем и улучшать взаимодействие команды.
Сначала рассмотрим наиболее часто используемыеСпецификация угловой команды.
Спецификация сообщения фиксации Angular
Спецификация делит информацию фиксации на три части: заголовок, тело и нижний колонтитул.
Ни одна строка ни в одной из трех частей не может превышать 100 символов! (Написано в документе спецификации angular)
Вот почему вам нужно ограничить длину символов, потому что git усекает часть темы коммита до более чем 72 символов. Эффект показан на следующем рисунке:
Формат сообщения фиксации Angular выглядит следующим образом:
<type>(<scope>): <subject> // 这一行是Header
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Часть Body относительно проста и необязательна, поскольку относится к конкретному описанию этого представления.
Раздел заголовка
Спецификация делит заголовок на три части: тип, объем и тема.
type
тип относится к типу этой отправки, который является обязательным и должен быть одним из следующих:
- подвиг: новая функция
- исправить: исправление ошибки
- документы: только изменения в документации
- стиль: изменения, не влияющие на смысл кода (пробелы, форматирование, отсутствие точек с запятой и т. д.)
- рефакторинг: изменения кода, которые не исправляют ошибки и не добавляют функциональности (рефакторинг)
- perf: изменения кода для повышения производительности
- тест: добавить отсутствующие или исправить существующие тесты
- build: изменения, влияющие на систему сборки или внешние зависимости (gulp, npm и т. д.)
- ci: изменения в конфигурационных файлах и скриптах CI
- рутинная работа: изменения в процессе сборки или вспомогательных инструментах и библиотеках, таких как генерация документации
scope
Область действия относится к области влияния этой фиксации, которая не является обязательной и может быть любой, указывающей местоположение изменения фиксации. Я обычно пишу измененную часть имени модуля или имени файла.
Звездочку (*) можно использовать, если изменение затрагивает более одной области действия. Конечно, вы можете оставить это поле пустым.
subject
тема относится к краткому описанию этого представления, которое имеет следующие два правила.
- Не делайте первую букву заглавной
- Без точки (.) в конце
Нижний колонтитул является необязательным и может включать следующие две ситуации.
- Была ли произведена деструктивная модификация
Если текущий код несовместим с предыдущей версией, например, обновление версии, уменьшение параметров интерфейса, удаление интерфейса, миграция и т. д., это деструктивная модификация.
Если это деструктивная модификация, раздел нижнего колонтитула будет начинаться с НАРУШАЮЩЕГО ИЗМЕНЕНИЯ, за которым следует описание изменения, причина изменения и метод переноса. следующим образом:
BREAKING CHANGE: 变动的描述\理由\迁移方法
- закрыть вопрос
Если текущая фиксация предназначена для проблемы, вы можете закрыть эту проблему в разделе нижнего колонтитула или закрыть несколько проблем. Заполните форму следующим образом:
Close #ISSUE_ID
Closes #ISSUE_ID, #ISSUE_ID
Если вы используете jira, вы также можете заполнить JIRA_ID, затронутый этой модификацией, но чтобы включить эту функцию, вам необходимо сначала интегрировать ееjira интегрируется с gitlab & jira интегрируется с github. Заполните форму следующим образом:
re #JIRA_ID // re是关于的意思
fix #JIRA_ID
Отправка в git в соответствии с указанным выше форматом будет выглядеть следующим образом:
Выше приведена спецификация фиксации команды Angular.Вы также можете настроить спецификацию фиксации в соответствии с привычками вашей команды.
Спецификация пользовательского сообщения фиксации
В этой части я познакомлю вас Я хочу настроить формат подачи в этом проекте Вы можете сделать выводы из одного случая.
Я думаю, что пользовательская спецификация основана на спецификации Angluar, просто добавьте поле emoji gitmoji вверху. Формат следующий:
:gitmoji: <type>(<scope>): <subject> // 这一行是Header
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Элемент gitmoji является обязательным, и значение может быть толькопредоставлено gitmojiСмайлик в списке смайликов.
Отправка в git в нужном мне формате отображается следующим образом:
Позвольте мне сначала рассказать об этом.Есть также выражения, написанные в спецификации Angluar.Вы должны использовать git-cz.Это выражение отображается в начале темы.Это не соответствует эффекту, который я хочу 😀, похоже это!
На данный момент формат спецификации коммита почти такой же! Конечно, с таким количеством запутанных правил мы не можем позволить всем писать их от руки! 🎉🎉🎉🎉Dangdangdang~ Давайте поиграем с инструментами!
Инструмент фиксации спецификации
Здесь давайте поговорим о том, как использовать инструменты для реализации спецификаций Anglar по умолчанию, а затем поговорим о пользовательских спецификациях. Будь то версия Angluar или пользовательская версия, нам понадобится следующий инструмент:
commitizen: это даст git cz Эта команда заменяет нашу команду git commit, что упрощает создание сообщения фиксации, соответствующего спецификации.
Угловое каноническое издание
Установить глобально
npm install -g commitizen
Инициализируйте предустановку фиксации, здесь используйте предустановку cz-conventional-changelog, которую предпочитает официальный сайт.
cz-conventional-changelog: это предпочтительный адаптер для коммитизена с конфигурацией по умолчанию, но вы также можете настроить тип, установить такие свойства, как длина заголовка и т. д. Однако его оперативная информация представлена на английском языке и не может быть изменена (находится в исходном коде). Если вам нужно настроить информацию о приглашении конфигурации, вам нужно использоватьcz-customizableАдаптер, пользовательская версия в конце статьи содержит эту часть контента,Нажмите здесь, чтобы отправить.
commitizen init cz-conventional-changelog --save-dev --save-exact
В глобальном режиме файл конфигурации ~/.czrc требуется, чтобы указать адаптер для фиксации.
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
Теперь каждый может использовать команду git cz или cz для отправки информации о коммите.
Глобальные установки могут выполнять команду git cz или cz вместо git commit в любом каталоге под git init.
Установить в проект
npm install commitizen cz-conventional-changelog -D
Настроенный в package.json, вот адаптер с cz-conventional-changelog, установленным на commitizen. Вы также можете выбрать другие адаптеры.В пользовательской версии в статье установлены другие адаптеры.Нажмите здесь, чтобы просмотреть.
"scripts": {
"commit": "cz"
}
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}
Для установки внутри проекта npm run commit можно использовать только вместо git commit в текущем каталоге проекта.
Для удобства использования команды cz я установил ее как глобально, так и внутри проекта.Следующее демонстрирует эффект:
На данный момент реализована автоматизация отправки коммитов. Однако cz-conventional-changelog не поддерживает смайлики, давайте поговорим о том, как добавить смайлики.
Отображение выражения в начале тематического раздела
Выражение начинается в начале тематического раздела, или выражения нет. Эффект подчинения выглядит следующим образом:
Для достижения этого эффекта необходимо использоватьstreamich/git-cz
1. Глобальная установка
Вы можете запустить команду git-cz, чтобы отправить фиксацию без загрузки commitizen.Если commitizen уже установлен, он перезапишет эффект команды git cz commitizen.
npm install -g git-cz
git-cz
2. Использование в проекте commitizen
npm install -D git-cz
package.json зафиксируйте в адаптере git-cz:
{
"config": {
"commitizen": {
"path": "git-cz"
}
}
}
выполните следующую команду
npx git-cz
Эффект следующий, отправленный коммит имеет выражение в начале темы:
😭Мое компьютерное выражение показывает искаженные символы, и это еще не решено (друзья, которые знают, как решить проблему, пожалуйста, сообщите мне в комментариях, я действительно не могу понять это 😰), но это просто искажено символов на компе, а на гитхабе он отображается нормально, так что это не сильно помешает моей сдаче, но мне просто неудобно на это смотреть.
Здесь также есть небольшая проблема.В моей реальной работе я обнаружил, что пока установлен git-cz, можно запустить команду npx git-cz, и отображаемый текст выбора также соответствует настройкам git по умолчанию. -cz, и никакой конфигурации package.json не требуется, не знаю, почему он не соответствует описанию на официальном сайте, пока не разобрался😥.
Инструмент git-cz также предоставляет пользовательскую конфигурацию, но элементы конфигурации ограничены. Добавьте changelog.config.js в корневой каталог.Ниже приведен пример официальной конфигурации.Вы можете найти его вофициальный streamich/git-czПосмотреть больше конфигураций.
./changelog.config.js
module.exports = {
"disableEmoji": false,
"list": [
"test",
"feat",
"fix",
"chore",
"docs",
"refactor",
"style",
"ci",
"perf"
],
"maxMessageLength": 64,
"minMessageLength": 3,
"questions": [
"type",
"scope",
"subject",
"body",
"breaking",
"issues",
"lerna"
],
"scopes": [],
"types": {
"chore": {
"description": "Build process or auxiliary tool changes",
"emoji": "🤖", // 当前类型的commit所显示的表情
"value": "chore"
},
"ci": {
"description": "CI related changes",
"emoji": "🎡",
"value": "ci"
},
"docs": {
"description": "Documentation only changes",
"emoji": "✏️",
"value": "docs"
},
"feat": {
"description": "A new feature",
"emoji": "🎸",
"value": "feat"
},
"fix": {
"description": "A bug fix",
"emoji": "🐛",
"value": "fix"
},
"perf": {
"description": "A code change that improves performance",
"emoji": "⚡️",
"value": "perf"
},
"refactor": {
"description": "A code change that neither fixes a bug or adds a feature",
"emoji": "💡",
"value": "refactor"
},
"release": {
"description": "Create a release commit",
"emoji": "🏹",
"value": "release"
},
"style": {
"description": "Markup, white-space, formatting, missing semi-colons...",
"emoji": "💄",
"value": "style"
},
"test": {
"description": "Adding missing tests",
"emoji": "💍",
"value": "test"
}
}
}
Этот вид коммитов не требует добавления дополнительных инструментов для обязательной проверки коммита.Этот формат соответствует спецификации angular, так как выражение относится к полю subject.По умолчанию проверка angular может быть пройдена. Поэтому некоторые люди хотят выразить фиксацию с помощью commitizen+git-cz.
Смайлик отображается в начале сообщения фиксации
Здесь я сначала представлю адаптер cz-emoji, рекомендованный официальным сайтом commitizen, но я не говорю о нем в этой теме. Информация фиксации, которую он отправляет, выглядит следующим образом:
cz-emoji: этот адаптер заменяет часть шрифта эмодзи. Так как это относительно просто, всем интересно увидеть его официальное описание на сайте, а как им пользоваться здесь не обсуждается.
Ну а здесь речь в основном идет о том, как добавить эмодзи на основе англуара, сохранить шрифт и добавить эмодзи :emoji: перед типом (это то, что я давно делаю 😂).Эта спецификация фиксации является спецификацией открытия выражения, о которой я упоминал выше.
Давайте сначала установим cz-customizable
npm i -D cz-customizable
package.json
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}
cz-customizable: это адаптер, используемый для настройки команды cz, вы можете настроить информацию о приглашении, тип, длину и т. д.
Добавьте .cz-config.js в корневую директорию проекта, чтобы добавить элементы конфигурации.Вы можете обратиться к официальному сайту за инструкциями и правилами для настройки вашего собственного проекта.Мой файл конфигурации выглядит следующим образом:
/.cz-config.js
module.exports = {
types: [
{
value: 'feat',
name: 'feat: 新功能'
},
{
value: 'fix',
name: 'fix: 修复bug'
},
{
value: 'init',
name: 'init: 初始化'
},
{
value: ':pencil2: docs',
name: 'docs: 文档变更'
},
{
value: 'style',
name: 'style: 代码的样式美化'
},
{
value: 'refactor',
name: 'refactor: 重构'
},
{
value: 'perf',
name: 'perf: 性能优化'
},
{
value: 'test',
name: 'test: 测试'
},
{
value: 'revert',
name: 'revert: 回退'
},
{
value: 'build',
name: 'build: 打包'
},
{
value: 'chore',
name: 'chore: 构建/工程依赖/工具'
},
{
value: 'ci',
name: 'ci: CI related changes'
}
],
messages: {
type: '请选择提交类型(必填)',
customScope: '请输入文件修改范围(可选)',
subject: '请简要描述提交(必填)',
body: '请输入详细描述(可选)',
breaking: '列出任何BREAKING CHANGES(可选)',
footer: '请输入要关闭的issue(可选)',
confirmCommit: '确定提交此说明吗？'
},
allowCustomScopes: true,
allowBreakingChanges: ['feat', 'fix'], // 当提交类型为feat、fix时才有破坏性修改选项
subjectLimit: 72
};
Теперь введите cz или git cz , эффект будет следующим:
Поскольку я хочу начать с эмодзи, я использовал хитрый метод, чтобы изменить поле типов .cz-config.js на следующее:
types: [
{
value: ':zap: feat',
name: '⚡ feat: 新功能'
},
...
]
Эффект выглядит следующим образом, то есть добавляется часть выражения, а другая такая же, как и вышеописанный эффект, поэтому изображение в формате gif не будет записано:
Привязка части значения к коду смайликов приведет к появлению смайликов. Код смайликов :zap: не используется, потому что нам нужно добавить информацию о подтверждении подтверждения позже. Смайлик подтверждения по умолчанию — это только код смайлика, который может пройти проверку. Этот формат, который мы настраиваем, не соответствует спецификации angular, и необходимо установить другие инструменты проверки. Вскоре!
Здесь используются все выраженияgitmojiСмайлики, представленные на этой странице, и смайлики для обязательной проверки информации о коммите позже также являются смайликами для проверки того, включены ли они в это. Этот код эмодзи по-прежнему отображается в командной строке, после отправки на github будет отображаться соответствующий эмодзи. Как показано ниже:
инструмент отправки кода vscode
Может быть, вы слишком ленивы, чтобы ввести команду для отправки коммита. Вот два плагина, которые я лично считаю подходящими для vscode, чтобы упомянуть код. Просто найдите и установите его в магазине расширений. Использование очень простое. Я сделаю. (После этого я напишу плагин vscode, соответствующий моим привычкам коммитов, и буду рекомендовать его всем в то время) 😁
Visual Studio Code Commitizen Support: Этот плагин - то, к чему я привык, он следует cz-customizable и создает необходимые файлы конфигурации, если в корневом каталоге вашего проекта есть конфигурация .cz-config.js, он будет отображать подсказки и проверки в соответствии с правилами этого файла конфигурации ( необходимо перезапустить vscode, чтобы он вступил в силу). Эффект от отправки этого плагина следующий:
Conventional Commits: Этот плагин может заполнять выражение (необязательно), формат соответствует спецификации выражения angular или angular+subject plus. Эффект от отправки этого плагина следующий:
Проверить спецификацию
Инструменты для упоминания кода выше могут облегчить каждому упомянуть код, но! Что если люди в вашей команде просто не следуют техническим требованиям и коду? Пришло время выставить Husky Contylint! Они могут проверить, является ли ваша информация Commit Canical, когда вы совершаете, а если нет, они не могут его отправить.
Эта часть также делится на угловую версию и пользовательскую версию смайликов, Прежде всего, независимо от версии описания, вам необходимо установить эти два инструмента:
husky: Как следует из названия, хаски, ха-ха, кусают и не отпускают. Этот инструмент используется для запуска команд в git-хуках, у которых есть проблемы, цепляющие вас за крючок. Обычно используется для выполнения команд, связанных с eslint, run test, commitlint.
commitlint: Об этом нечего сказать, это проверка вашей информации о коммите и предоставление различных общих конфигураций.
Подтвердить проверку сообщения
Во-первых, скачайте husky и commitlint.
npm i -D husky commitlint
Создайте файл .commitlintrc.js или commitlint.config.js. commitlint найдет этот файл, как указано в документе, расширяет информацию о контрольной сумме фиксации. Вы также можете настроить некоторые параметрыправило.
угловая версия
Чтобы проверить информацию о спецификации фиксации angular, содержимое выглядит следующим образом:
/.commitlintrc.js
module.exports = {
extends: ['@commitlint/config-conventional']
};
@commitlint/config-conventional проверен по спецификации angular, можно использовать и другие или написать линт самому и отправить в npm.
эмодзи стартер
Проверьте информацию о спецификации коммита в начале смайлика, о котором я упоминал выше. Commitlint не имеет встроенной подходящей общей конфигурации. Это требует от вас написания соответствующей конфигурации. К счастью, кто-то уже написал такую общую конфигурацию. Вот я воспользуйся интернетом, я нашел это, написанное боссом пустой долиныcommitlint-config-gitmoji.
npm i -D commitlint-config-gitmoji
Содержание следующее:
/.commitlintrc.js
module.exports = {
extends: ['gitmoji']
};
Commitlint настроен, давайте реализуем обязательную проверку при отправке.
хаски в обязательном порядке проверяет информацию о коммите
Выполните следующую команду, чтобы создать папку .kusky в корневом каталоге проекта. (Хаски по умолчанию под всеми тут последняя версия 5.0)
npx husky install
Создайте файл commit-msg в папке .husky (будьте осторожны, чтобы не встроить его в папку husky/_), содержимое будет следующим:
#!/bin/sh
npx --no-install commitlint --edit "$1"
В это время, когда мы снова отправим код, мы перейдем к хуку commit-msg и выполним команду, которую мы написали, чтобы проверить фиксацию.Когда информация фиксации не соответствует спецификации, commitlint подскажет, где правила неверны. , и хаски заблокирует текущий коммит, информация недоступна. Он реализован для обеспечения соответствия определенной спецификации фиксации, и вы не можете просто случайным образом упомянуть код! ! !
Далее поговорим о проверке кода и выполнении тестов перед фиксацией.
Проверка спецификации кода и запуск теста
Хотя все наши редакторы имеют плагины eslint для автоматического восстановления кода, мы, как правило, не отправляем код, который не соответствует eslint, но некоторые студенты действительно могут не устанавливать этот плагин без автоматического восстановления и вслепую писать код, не видя эффекта, так что просто в случае, если необходимо проверить спецификацию кода и протестировать перед фиксацией, чтобы убедиться, что код, который вы упомянули, соответствует спецификации и прошел тест🤣, хахаха! ! !
Во-первых, нам нужно установитьlint-staged, Многие люди не используют lint-staged, а напрямую запускают npm run lint в хуке pre-commit.Есть проблема.Если проект большой, вы изменяете только один файл, но он все равно проверит все файлы в src, что приведет к тому, что упоминать код слишком медленно, чтобы долго ждать. И lint-staged может решить эту проблему, он проверит только ту часть файла, которую вы изменяете. Что ж, давайте начнем после понимания причины и следствия~
npm i -D lint-staged
package.json
"scripts": {
"lint": "vue-cli-service lint --fix",
"test": "your-cmd"
},
"lint-staged": {
"src/**/*.scss": [
"stylelint --fix"
],
"src/**/*.{js,vue,ts,tsx}": "npm run lint"
}
Создайте файл предварительной фиксации в папке .kusky со следующим содержимым:
#!/bin/sh
npx --no-install lint-staged
npm run test
Здесь, когда вы отправляете код, он автоматически проверяет и исправляет отправленный код. Далее мы начинаем говорить об автоматической генерации CHANGELOG.
CHANGELOG автоматически генерируется
CHANGELOG выглядит так:
Во-первых, давайте поговорим о том, что такое CHANGELOG и зачем нам CHANGELOG? Он записывает всю информацию о фиксации вашего проекта и классифицирует версию, вы можете быстро перейти к записи фиксации и даже сразу отобразить информацию о модифицирующем лице и создателе, который обнаружил ошибку с первого взгляда 😂. Это позволяет вам легко узнать, какая версия проекта содержит какие функции, какие ошибки и другую информацию. Также удобно устранять ошибки, а записи о представлении ясны с первого взгляда, поэтому нет необходимости просматривать их одну за другой.
Здесь стандартная версия используется непосредственно для автоматического создания CHANGELOG. Про конвенциональный-чейнджлог мы говорить не будем, он ведь рекомендует нам использовать стандартную-версию (это все от той же команды, на основе конвенционального-чейнджлога). Относительно того, почему рекомендуется стандартная версия, прочтите официальное объяснение самостоятельно!официальный адресдля всех.
Я больше не говорю о семантическом выпуске, потому что я не проводил много исследований по CI/CD, поэтому я не могу говорить об этом 😂!официальный адресЗдесь также естьРекомендуемая статьяКому интересно, может прочитать.
Что ж, приступим к реализации со стандартной версии! Загрузите сначала~
npm i -D standard-version
package.json
{
"scripts": {
"release": "standard-version"
}
}
Выполните следующую команду, и файл CHANGELOG.md будет автоматически сгенерирован на основе вашей информации о коммите.
npm run release
Выполните эту команду, когда ваш тип фиксации — feat and fix, она автоматически увеличит номер версии.
Вот небольшая проблема, которую я обнаружил во время отладки.После того, как вы выполните ее один раз, если вы удалите файл CHANGELOG.md и больше не будете изменять отправку, а затем снова выполните команду сборки, она сгенерирует для вас только один номер версии Файл, вы должны отправить его, а затем выполнить его, чтобы иметь журнал фиксации, но записи до этой отправки не будут отображаться снова (очень странно, обратите внимание на эту проблему при отладке).
standard-versionПредоставьте пользовательскую конфигурацию для различных типов соответствующего отображаемого текста и создайте новый файл versionrc.js в корневом каталоге.Здесь я приведу пример своего содержимого versionrc.js:
module.exports = {
"types": [
{ "type": "feat", "section": "✨ Features | 新功能" },
{ "type": "fix", "section": "🐛 Bug Fixes | Bug 修复" },
{ "type": "init", "section": "🎉 Init | 初始化" },
{ "type": "docs", "section": "✏️ Documentation | 文档" },
{ "type": "style", "section": "💄 Styles | 风格" },
{ "type": "refactor", "section": "♻️ Code Refactoring | 代码重构" },
{ "type": "perf", "section": "⚡ Performance Improvements | 性能优化" },
{ "type": "test", "section": "✅ Tests | 测试" },
{ "type": "revert", "section": "⏪ Revert | 回退" },
{ "type": "build", "section": "📦 Build System | 打包构建" },
{ "type": "chore", "section": "🚀 Chore | 构建/工程依赖/工具" },
{ "type": "ci", "section": "👷 Continuous Integration | CI 配置" }
]
}
После настройки мой CHANGELOG выглядит так!
Здесь следует упомянуть, что по умолчанию для стандартной версии используется angular.Как и коммит, который мы использовали для настройки выражения ранее, спецификация отличается от angular.Он не может читать журнал изменений, сгенерированный соответствующим типом, и не может быть классифицирован. Старший брат инструмента commitlint-config-gitmoji написал инструмент для создания CHANGELOG в соответствии с форматом :emoji: type: …conventional-changelog-gitmoji-configНу, давайте использовать его прямо здесь! Однако этот инструмент не предоставляет функции настройки копии типа конфигурации.Он написан в исходном коде, поэтому с помощью этого инструмента нельзя настроить, как в версии rc.js выше, но он поставляется с ним.Эмодзи также поддерживает как китайский и английский, а также поддерживает отображение модификаторов и почтовых ящиков, что тоже очень мощно! ! ! 🉑
Давай сначала скачаем~
npm i -D conventional-changelog-gitmoji-config
стандартная версия указывает дополнительные пресеты с помощью команды --preset (найдена в исходном коде)
{
"scripts": {
"release": "standard-version --preset gitmoji-config"
}
}
Объясните здесь, почему --preset gitmoji-config может читать пресет, этот пакет явно называется конвенциональным-changelog-gitmoji-config, это потому, что конвенциональный-чейнджлог-пресет-загрузчик находит пресет, когда ищет обычный-чейнджлог- xxx, префикс условный-changelog-, скриншот исходного кода здесь:
Я не делал CI/CD и не использовал стандартную версию.Для удобства я напрямую выполняю команду для создания CHANGELOG в pre-push hook~
.husky/pre-push
#!/bin/sh
npm run release
Таким образом, когда я выполняю git push, CHANGELOG.md будет автоматически сгенерирован и отправлен на удаленный конец, поэтому нет необходимости вручную выполнять команду npm run release для повторного нажатия. ла ла ла 🎈🎈🎈
Это наконец закончилось! Спасибо, что так долго меня слушали. Надеюсь, я смогу вам помочь. Если в статье есть ошибки или неточности, пожалуйста, поправьте меня. Спасибо вам всем! ! ! 😜
использованная литература
Описание официальной спецификации Angular
Статья Baidu о языке г-на Кун Гу, который никогда не встречался с г-ном Конгом.
Изящно зафиксируйте сообщение Git Commit Message
А также документацию и исходники каждого инструмента в тексте, я не буду перечислять их по порядку.