Сделайте это одним куском Обычные коммиты

внешний интерфейс Git спецификация кода
Сделайте это одним куском Обычные коммиты

Привет всем, яЛуожу🎋, деревянный фронтенд, живущий в Ханчжоу 🧚🏻‍♀️, если вам понравилась моя статья 📚, вы можете помочь мне собрать духовную силу ⭐️ лайком.

Лучшие практики, описанные в этой статье, были добавлены в прогрессивную систему строительных лесов Луожу, реализующуюnpx @luozhu/create-commitlintдля расширения возможностей проекта.

предисловие

нормализоватьgit commitдля улучшенияgit logУдобочитаемость, контролируемый контроль версий и генерация журнала изменений играют важную роль. Однако нам мешает не только раскрутка команды, но и конфигурация одной только серии инструментов непосильна. Основными из них являются комбинированное использование commitlint и commitizen, а также спецификация пользовательского коммита. В этой статье собраны текущие рекомендации для всех. Если это поможет, звезды достаточно.

Обычные коммиты

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

Описание коммита структурировано следующим образом:

<类型>([可选的作用域]): <描述>

[可选的正文]

[可选的脚注]

тип

  • feat:: типfeat's commit указывает, что в кодовую базу была добавлена ​​новая функция (это то же самое, что и семантическая версияMINORСоответствующий).
  • fix:: типfixКоммит указывает, что ошибка была исправлена ​​в кодовой базе (это то же самое, что иPATCHСоответствующий).
  • docs:: просто измените документ.
  • style:: Изменения, не влияющие на смысл кода (пробелы, форматирование, отсутствие точек с запятой и т.д.).
  • refactor:: Рефакторинг кода, который не исправляет ошибки и не добавляет функциональности.
  • perf:: изменения кода для повышения производительности.
  • test:: добавить фактический тест или исправить существующий тест.
  • build:: Изменения, влияющие на систему сборки или внешние зависимости (пример области действия: gulp, broccoli, npm).
  • ci:: изменение файлов и сценариев непрерывной интеграции (примеры диапазонов: Travis, Circle, BrowserStack, SauceLabs).
  • chore:: Другие не модифицируютсяsrcилиtestдокумент.
  • revert:: совершить откат.

объем

К типу фиксации можно добавить область в скобках, чтобы предоставить дополнительную контекстную информацию. Напримерfeat(parser): adds ability to parse arrays..

BREAKING CHANGE

С начальной позицией необязательного тела или сноскиBREAKING CHANGE:, указывающее на введение критического изменения API (это то же самое, что и в Semantic Versioning).MAJORСоответствующий). Критические изменения могут быть произвольнымиТипычасть подачи.

Пример

Включите описание и инструкции по коммиту для критических изменений в теле

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config files

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

chore!: drop Node 6 from testing matrix

BREAKING CHANGE: dropping Node 6 which hits end of life in April

Инструкции по отправке без тела

docs: correct spelling of CHANGELOG

Инструкции фиксации с областью действия

feat(lang): add polish language

Зафиксируйте описание исправления, включая (необязательно) номер проблемы.

fix: correct minor typos in code

see the issue for details on the typos fixed

closes issue #12

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

  1. каждый коммитдолженИспользуйте префикс поля типа, который состоит из существительного, такого какfeatилиfix, за которым следуетнеобязательныйобласти видимости инеобходимоДвоеточие (англ. half-width) и пробел.
  2. Когда коммит реализует новую функцию для приложения или библиотеки,должениспользоватьfeatТипы.
  3. Когда коммит исправляет ошибку в приложении,должениспользоватьfixТипы.
  4. Поле области действия может следовать за полем типа. роль имеетдолженэто существительное, описывающее раздел кода и заключенное в круглые скобки, например:fix(parser):
  5. Поле описаниядолженСразу после пробела в префиксе типа/области. Описание относится к краткому изложению изменения кода, например:fix:array parsing issue when multiplejspaces were contained in string.
  6. После краткого описания,МогуНапишите более длинные тела коммитов, чтобы обеспечить дополнительный контекст для изменений кода. текстдолженНачинается после пустой строки в конце поля описания.
  7. После пустой строки в конце текстаМогуНапишите одну или несколько строк сносок. сноскадолженСодержит метаинформацию о коммите, например связанные запросы на слияние, рецензентов, критические изменения, по одной строке на метаинформацию.
  8. критические изменениядолженОтмечается в самом начале текстовой области или в начале строки в области сноски. критическое изменениедолженсодержит текст в верхнем регистреBREAKING CHANGE, за которым следует двоеточие и пробел.
  9. существуетBREAKING CHANGE:ПозжедолженПредоставьте описание для описания изменений в API. Например:BREAKING CHANGE: enviroment variables now take precedence over cofig files.
  10. В инструкции по подачеМогуиспользоватьfeatа такжеfixдругие типы.
  11. Реализация инструментане долженАнализировать с учетом регистра информационные единицы, составляющие контрактную заявку, толькоBREAKING CHANGE долженпишется с большой буквы.
  12. МогуПосле префикса типа/области:перед добавлением!символ для дальнейшего привлечения внимания к критическим изменениям. когда есть!префикс, текст или сноски должны содержатьBREAKING CHANGE: description

Зачем использовать фиксацию по соглашению

  • Автоматизированное производство CHANGELOG.
  • Изменения семантической версии определяются автоматически в зависимости от типа фиксации.
  • Сообщите о характере изменений коллегам, общественности и другим заинтересованным сторонам.
  • Запустите процессы сборки и развертывания.
  • Позвольте людям изучить более структурированную историю коммитов, чтобы облегчить участие в вашем проекте.

cz-customizable

Настраиваемый подключаемый модуль Commitizen (или автономная утилита) помогает получать согласованные сообщения фиксации.

Установите commitizen, настраиваемый cz:

$ yarn add -D commitizen cz-customizable

Добавьте новый скрипт в package.json:

{
  "scripts" : {
    ...
    "commit": "git cz"
  }
  "config": {
    "commitizen": {
      "path": "cz-customizable"
    }
  }
}

Новое в корневом каталоге.cz-config.jsи копироватьcz-config-EXAMPLE.jsв файл.

Эффект:

commitlint

commitlint проверяет, соответствует ли ваше сообщение коммитаconventional commit format.

1. Установите @commitlint/cli, yorkie:

$ yarn add -D @commitlint/cli yorkie

2. Добавьте хуки git commit в package.json:

{
  ...
  "gitHooks": {
    "commit-msg": "commitlint -e -V"
  }
}

3. Установите commitlint-config-cz:

commitlint-config-cz объединяет конфигурацию cz-customizable{types,scopes,scopeOverrides}и конфигурация фиксации{type-enum,scope-enum}. Таким образом, вы можете поддерживать типы и области видимости в одном месте.

$ yarn add commitlint-config-cz -D

4. Вcommitlint.config.jsкитайское использованиеczРасширьте конфигурацию коммита:

module.exports = {
  extends: ['cz'],
  rules: {
    // must add these rules
    'type-empty': [2, 'never'],
    'subject-empty': [2, 'never']
  }
};

vscode commitizen

Найдите и установите vscode commitizen в VS Code, тогда вы сможете избавиться от командной строки, и этот плагин совместим со всеми предыдущими конфигурациями, эффект будет следующим:

GitHub Actions

Создайте новый рабочий процесс github.github/workflows/commitlint.yml, роль заключается в проверке информации при отправке pull_request:

name: Lint Commit Messages
on: [pull_request]

jobs:
  commitlint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v1
        with:
          node-version: '10.x'
      - run: npm install
      - name: Add dependencies for commitlint action
        # $GITHUB_WORKSPACE is the path to your repository
        run: echo "::set-env name=NODE_PATH::$GITHUB_WORKSPACE/node_modules"
      # Now the commitlint action will run considering its own dependencies and yours as well 🚀
      - uses: wagoid/commitlint-github-action@v2

standard-version

standard-versionявляется последователемСемантическое управление версиями (semver)а такжеСтандартная спецификация сообщения фиксацииинструмент автоматизации версии и журнала изменений. При нормальных обстоятельствах мы будем выполнять следующие операции выпуска версии в основной ветке:

  1. git pull origin master
  2. согласно сpackage.jsonсерединаversionОбновить номер версии, обновить CHANGELOG
  3. git add .
  4. git commit
  5. git tagоперация версии
  6. git push --tags: отправить тег версии и основную ветку в репозиторий

в2, 3, 4, 5Это работа, которую инструмент стандартной версии автоматически завершит. С помощью локальных сценариев оболочки он может автоматически завершить работу по выпуску серии версий.

Установить и использовать

$ yarn add -D standard-version

// package.json
{
  "scripts": {
    "release": "standard-version"
  }
}
  • Первый выпуск:yarn release --first-release
  • Релиз выпуска:yarn release
  • Выпуск в качестве предварительной версии:yarn release --prerelease or yarn release --prerelease alpha
  • Release as a Target Type Imperatively (npm version-подобно):yarn release --release-as minor or yarn release --release-as 1.1.0, которые можно комбинировать--prereleaseЭто упрощает выпуск экспериментальных функций.
  • Предотвратить хуки Git:yarn release --no-verify

Эта статья была впервые опубликована в "Официальный сайт Луожу", синхронизировано с официальным аккаунтом"Дом утреннего чая в Луочжу"а также"Колонка самородков".

Категории