Заголовок: Если вам понравилась наша статья, не забудьте нажать и подписаться на специальный выпуск Ali Nanjing Technology~ Эта статья воспроизведена изСпециальный выпуск Alibaba Nanjing Technology — Знание, приветствуем Даниэля и Маверикс для публикации вакансий, таких как разработка клиентского/внутреннего интерфейса Alibaba Nanjing, подробности см.Alibaba Nanjing искренне приглашает внешних партнеров присоединиться~.
Сообщение о коммите — это ежедневная операция разработки.Ведение журнала не только полезно для просмотра другими, но также может эффективно выводить CHANGELOG, который очень важен для управления проектом, но часто игнорируется в практической работе. Я надеюсь, что с помощью этой статьи я смогу помочь вам обратить внимание и стандартизировать написание сообщений коммитов.
причина
Есть вопрос по Жиху:Как написать хороший журнал коммитов Git?Очень интересно увидеть различные стили отправки: полезные смайлики, полезная танская поэзия, полезная случайная генерация.Нет правильного или неправильного стиля, пока он может отражать изменения, внесенные коммитом.
Но больше всего меня поразил ответ @李华桥:
Такого рода вещи, конечно, требуют помощи инструментов, чтобы их можно было записать в стандартизированном и отформатированном виде, а также поддерживать последующий анализ. Текущая рекомендация - использовать инструмент терминалаcommitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-versionОдношаговое разрешение сообщений о фиксации и выпусков версий.
Даже, если вы хотите быть более агрессивным, добавьте его в непрерывную интеграцию.marionebl/commitlintНевозможно проверить, соответствует ли информация фиксации спецификации.
Эта статья следует этому направлению и знакомит с тем, как обеспечить спецификацию и форматирование сообщения фиксации проекта.
Формат сообщения фиксации
В настоящее время наиболее часто используемым стандартом являетсяСпецификации от команды Angular, что привело кConventional Commits specification, Многие инструменты также основаны на этой спецификации, и ее формат сообщения выглядит следующим образом:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Мы выводим с помощью командного интерфейса vim git commit аналогичный конечный результат, который должен заполнить приведенную выше структуру, примерно разделенную на три части (разделенные пустые строки):
- Строка заголовка: обязательна, описывает основные типы и модифицирует содержимое.
- Содержание темы: Опишите, почему была сделана модификация, какая модификация была сделана, а также идеи развития и т. д.
- Примечания в нижнем колонтитуле: внесите критические изменения или закрытые проблемы
Он состоит из следующих частей:
- тип: тип фиксации
- подвиг: новые возможности
- исправить: решить проблему
- рефакторинг: рефакторинг кода
- документы: Изменения в документации
- стиль: модификация формата кода, обратите внимание, что это не модификация css
- тест: модификация тестового примера
- рутинная работа: другие модификации, такие как процесс сборки, управление зависимостями.
- scope: область затронутой фиксации, например: маршрут, компонент, утилиты, сборка...
- тема: обзор коммита, предполагаемое соответствие50/72 formatting
- body: зафиксируйте конкретное содержимое модификации, которое можно разделить на несколько строк, рекомендуется соблюдать50/72 formatting
- нижний колонтитул: некоторые примечания, обычно ссылка на КРИТИЧЕСКОЕ ИЗМЕНЕНИЕ или исправленную ошибку.
Такое стандартное сообщение коммита похоже на электронное письмо.
шаблон коммита git
Если вы просто личный проект или хотите попробовать такой стандартизированный формат, то вы можете установить шаблон коммита для git и выводить его в vim каждый раз, когда вы коммитите git, всегда напоминайте себе:
Измените ~/.gitconfig, добавьте:
[commit]
template = ~/.gitmessage
Содержимое нового ~/.gitmessage может быть следующим:
# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#
Commitizen: замените ваш коммит git
Наша цель — генерировать и ограничивать с помощью инструментов, так что давайте начнем прямо сейчас.
commitizen/cz-cli, нам нужно использовать команду git cz, которую он предоставляет, чтобы заменить нашу команду git commit, чтобы помочь нам сгенерировать сообщение фиксации, соответствующее спецификации.
Кроме того, нам также нужно указать адаптер для фиксации, например:cz-conventional-changelog(Предустановка, соответствующая спецификациям команды Angular.) Make commitizen помогает нам генерировать сообщения коммитов в соответствии с указанными нами спецификациями.
Установить глобально
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
В основном, в глобальном режиме файл конфигурации ~/.czrc требуется для указания адаптера для фиксации.
Установка на уровне проекта
npm install -D commitizen cz-conventional-changelog
Конфигурация в package.json:
"script": {
...,
"commit": "git-cz",
},
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
}
Если commitizen был установлен глобально, вы можете выполнить git cz или npm run commit в соответствующем проекте.
Эффект следующий:
пользовательский адаптер
Возможно, мы не привыкли к набору спецификаций Angular, тогда мы можем указать Adaptercz-customizableУкажите набор спецификаций, которые подходят вашей команде.
Глобальная установка или установка на уровне проекта:
npm i -g cz-customizable
or
npm i -D cz-customizable
Измените конфигурацию в .czrc или package.json, чтобы:
{ "path": "cz-customizable" }
or
"config": {
"commitizen": {
"path": "node_modules/cz-customizable"
}
}
В то же время создайте файл .cz-config.js в ~/ или каталоге проекта, сохранив нужный формат: Например, мой файл конфигурации:leohxj/.cz-config
Эффект следующий:
Commitlint: подтвердите свое сообщение
commitlint: Это может помочь нам анализировать сообщения фиксации.Если то, что мы отправляем, не соответствует указанным спецификациям, более безжалостно напрямую отклонять отправку.
Точно так же для этого также требуется конфигурация проверки, которая рекомендуется здесь.@commitlint/config-conventional(Соответствует спецификациям команды Angular).
Установить:
npm i -D @commitlint/config-conventional @commitlint/cli
При этом нужно создать конфигурационный файл .commitlintrc.js в каталоге проекта, и написать:
module.exports = {
extends: [
''@commitlint/config-conventional''
],
rules: {
}
};
Lint для пользовательских адаптеров
Если вы, как и я, используете собственный адаптер фиксации, вам нужно:
npm i -D commitlint-config-cz @commitlint/cli
Напишите в .commitlintrc.js:
module.exports = {
extends: [
'cz'
],
rules: {
}
};
Объединить хаски
Лучший способ проверить сообщение коммита — объединить git hook, поэтому он должен сотрудничатьHusky.
npm i husky@next
Добавьте в package.json:
"husky": {
"hooks": {
...,
"commit-msg": "commitlint -e $GIT_PARAMS"
}
},
Эффект следующий:
стандартная версия: автоматически генерировать CHANGELOG
С помощью вышеперечисленных инструментов сообщение фиксации нашего проекта должно соответствовать набору команды Angular, что также удобно для нас в использовании.standard-versionТакие инструменты автоматически генерируют CHANGELOG и даже семантические номера версий (Semantic Version).
Установить с помощью:
npm i -S standard-version
Конфигурация package.json:
"scirpt": {
...,
"release": "standard-version"
}
PS: стандартная версия имеет много других функций, которые здесь не покрываются. Заинтересованные студенты могут попробовать его сами по себе.
наконец
Стандартизация сообщения о коммите очень важна, но нужно ли вводить ограничения, как в этой статье, у каждой команды и у каждого свои идеи, но лично подумайте: хорошие привычки, польза для жизни.