введение
В повседневной работе мы обычно используем git для управления кодом.Когда мы вносим какие-то изменения в код, мы можем отправить код через git commit.
Git требует, чтобы информация об отправке должна быть записана при отправке.Как описание изменения, она сохраняется в истории коммитов для легкого возврата. Стандартизированный журнал не только полезен для просмотра другими, но также может эффективно выводить CHANGELOG и даже значительно повышать качество исследований и разработок проекта.
Однако в повседневной работе большинство студентов просто записывают лог-информацию и не уделяют ей особого внимания, что, несомненно, недружественно к управлению и сопровождению проекта. Эта статья в основном основана на моем собственном опыте, чтобы поделиться с вами некоторыми спецификациями git commit, чтобы ваш журнал был не только «красивым», но и «практичным».
Зачем стандартизировать git commit
Было сказано стандартизировать формат фиксации, так зачем это делать?
Давайте сначала посмотрим на нестандартную запись коммита:
Что вы чувствуете после прочтения, что там написано (внутренняя ОС), эта коммитная информация, несомненно, является смертельным ударом для тех, кто хочет получить из нее действенную информацию.
Тогда давайте посмотрим на наиболее популярные в сообществе.Angular规范Запись фиксации:
Это очевидно после прочтения?
Информация о канонической фиксации на приведенном выше рисунке сначала предоставляет больше исторической информации для быстрого просмотра. Во-вторых, вы можете фильтровать определенные фиксации (например, изменения документа) для быстрого поиска информации.
Так как было сказаноAngular 团队的规范Это самая популярная спецификация фиксации в сообществе, так что же это такое? Давайте подробнее рассмотрим ниже.
Спецификация фиксации команды Angular
Формат его сообщения следующий:
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
Соответствует трем частям сообщения фиксации:Header,Bodyа такжеFooter.
Header
Раздел «Заголовок» состоит всего из одной строки и включает в себя три поля:type(требуется),scope(необязательно) иsubject(требуется).
-
type: Используется для указания типа фиксации. Как правило, есть следующие:feat: 新增feature fix: 修复bug docs: 仅仅修改了文档，如readme.md style: 仅仅是对格式进行修改，如逗号、缩进、空格等。不改变代码逻辑。 refactor: 代码重构，没有新增功能或修复bug perf: 优化相关，如提升性能、用户体验等。 test: 测试用例，包括单元测试、集成测试。 chore: 改变构建流程、或者增加依赖库、工具等。 revert: 版本回滚 -
scope: Используется для описания области влияния коммита, например: представления, компоненты, утилиты, тесты... -
subject: краткое описание цели коммита
Body
Конкретное описание измененного содержимого этой фиксации можно разделить на несколько строк. Следующим образом:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commit
Footer
некоторые замечания, обычноBREAKING CHANGE(текущий код не совместим с предыдущей версией) или ссылки на исправленные ошибки (закрыть проблему).
После краткого ознакомления с приведенными выше спецификациями, давайте поговорим оcommit.template, который является шаблоном сообщения фиксации git.
шаблон сообщения фиксации git
Если у вашей команды есть требования к форматированию коммитов, создайте файл в своей системе и настройте git для использования его в качестве шаблона по умолчанию, чтобы облегчить выполнение коммитов в соответствии с форматированием.
Настройте шаблон сообщения фиксации с помощью следующей команды:
git config commit.template [模板文件名] //这个命令只能设置当前分支的提交模板
git config — —global commit.template [模板文件名] //这个命令能设置全局的提交模板，注意global前面是两杠
новый.gitmessage.txt(файл шаблона) может быть следующим:
# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - 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 issue.
# - BREAKING CHANGE
#
Прочитав вышеизложенное, вы почувствуете, как и я, что настраивать очень хлопотно, а настройка почти идеальной спецификации коммита, подходящей для вас и вашей команды, не кажется легкой задачей. Тем не менее, сообщество также предоставило нам некоторые вспомогательные инструменты для помощи в отправке, давайте кратко представим эти инструменты.
коммитизен (cz-cli)
commitizenЭто инструмент, который может в интерактивном режиме создавать информацию о представлении. Это помогает нам шаг за шагом строить информацию об отправке из типа, и конкретный эффект показан на рисунке:
-
Во-первых, по контрольным точкам верхней и нижней связи к нужному типу типа, это соответствует вышеупомянутому
feat,fix,docs,perfЖдать: -
Затем он позволит вам выбрать файлы, затронутые этой фиксацией:
-
Следующее попросит вас написать краткое и подробное описание коммита соответственно:
- В конце концов, это позволит вам решить, является ли эта фиксация
BREAKING CHANGEили имеет включенную ассоциациюissue:
Прочитав весь процесс фиксации выше, давайте посмотрим, как его установить.
-
Установить в глобальном окружении:
совершать в соответствии с различными
adapterНастройте сообщение фиксации. Например, чтобы использовать формат сообщения фиксации Angular, вы можете установитьcz-conventional-changelog.# 需要同时安装commitizen和cz-conventional-changelog，后者是adapter $ npm install -g commitizen cz-conventional-changelog # 配置安装的adapter $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc # 使用 $ git cz
-
Локальная установка проекта:
# 安装commitizen $ npm install --save-dev commitizen # 接下来安装适配器 # for npm >= 5.2 $ npx commitizen init cz-conventional-changelog --save-dev --save-exact # for npm < 5.2 $ ./node_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact // package.json script字段中添加commit命令 "scripts": { "commit": "git-cz" } // use $ npm run commit
commitlint
commitlintявляется инструментом проверки отправки. Принцип заключается в том, что git-хуки можно использовать для проверки информации до того, как фактическая фиксация git будет зафиксирована в удаленном репозитории. Отправка информации, которая не соответствует правилам, будет заблокирована для отправки в удаленный репозиторий.
Давайте сначала посмотрим на демо:
дляConventional CommitsСпецификация, сообщество разобралось@commitlint/config-conventionalpackage, нам просто нужно установить и включить его.
Сначала установите commitlint и обычную спецификацию:
npm install --save-dev @commitlint/cli @commitlint/config-conventional
затем вpackage.jsonСредняя конфигурацияcommitlintсценарий:
"commitlint": {
"extends": [
"@commitlint/config-conventional"
]
},
Конечно, если вы хотите настроить commitlint отдельно, вам нужно создать файл проверки
commitlint.config.js, иначе проверка не пройдет
Чтобы иметь возможность выполнять commitlint каждый раз, когда мы фиксируем проверку введенного нами сообщения, нам также нужно использовать инструмент —husky.
хаски - усиленныйgit hookинструмент.可以在 git hook 的各个阶段执行我们在 package.json 中配置好的 npm script。
Сначала установите хаски:
npm install --save-dev husky
затем вpackage.jsonСредняя конфигурацияcommitmsgсценарий:
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
сюда,commitlintНастройка завершена~
gitmoji-cli
При общении с друзьями мы обязательно будем использовать смайлики, например. Появление смайликов делает общение между нами и нашими друзьями более интересным. Если вы можете использовать смайлики, когда git отправляет коммиты, разве это не сделает каждый коммит более интуитивно понятным и простым в обслуживании?
gitmojiЭто то, что мы можем достичь этой функции плагинов, давайте почувствовать
Ты чувствуешь себя круто~~
фактическиgitmojiИспользование очень простое:
# 安装
npm i -g gitmoji-cli
# 使用
git commit -m ':bug: 问题fix'
Давайте посмотрим на официальный пример:
Вам не терпится попробовать?
После прочтения этой статьи вы чувствуетеgit commit messageЕсть новое понимание? Идите и используйте их в своем проекте, сделайте свою фиксацию более стандартизированной и не забудьте добавить в свой журналemojiОй!
Наконец, прикрепите конфигурацию предыдущего проекта для git commitpackage.json,Ссылка:
{
"name": "ts-axios",
"version": "0.0.0",
"description": "",
"keywords": [],
"main": "dist/ts-axios.umd.js",
"module": "dist/ts-axios.es5.js",
"typings": "dist/types/ts-axios.d.ts",
"files": [
"dist"
],
"author": "fengshuan <1263215592@qq.com>",
"repository": {
"type": "git",
"url": ""
},
"license": "MIT",
"engines": {
"node": ">=6.0.0"
},
"scripts": {
"dev": "node examples/server.js",
"lint": "tslint --project tsconfig.json -t codeFrame 'src/**/*.ts' 'test/**/*.ts'",
"prebuild": "rimraf dist",
"build": "tsc --module commonjs && rollup -c rollup.config.ts && typedoc --out docs --target es6 --theme minimal --mode file src",
"start": "rollup -c rollup.config.ts -w",
"test": "jest --coverage",
"test:watch": "jest --coverage --watch",
"test:prod": "npm run lint && npm run test -- --no-cache",
"deploy-docs": "ts-node tools/gh-pages-publish",
"report-coverage": "cat ./coverage/lcov.info | coveralls",
"commit": "git-cz",
"semantic-release": "semantic-release",
"semantic-release-prepare": "ts-node tools/semantic-release-prepare",
"precommit": "lint-staged",
"travis-deploy-once": "travis-deploy-once"
},
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"lint-staged": {
"{src,test}/**/*.ts": [
"prettier --write",
"git add"
]
},
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
},
"jest": {
"transform": {
".(ts|tsx)": "ts-jest"
},
"testEnvironment": "node",
"testRegex": "(/__tests__/.*|\\.(test|spec))\\.(ts|tsx|js)$",
"moduleFileExtensions": [
"ts",
"tsx",
"js"
],
"coveragePathIgnorePatterns": [
"/node_modules/",
"/test/"
],
"coverageThreshold": {
"global": {
"branches": 90,
"functions": 95,
"lines": 95,
"statements": 95
}
},
"collectCoverageFrom": [
"src/*.{js,ts}"
]
},
"prettier": {
"semi": false,
"singleQuote": true
},
"commitlint": {
"extends": [
"@commitlint/config-conventional"
]
},
"devDependencies": {
"@commitlint/cli": "^7.1.2",
"@commitlint/config-conventional": "^7.1.2",
"@types/jest": "^23.3.2",
"@types/node": "^10.11.0",
"body-parser": "^1.19.0",
"colors": "^1.3.2",
"commitizen": "^3.0.0",
"coveralls": "^3.0.2",
"cross-env": "^5.2.0",
"cz-conventional-changelog": "^2.1.0",
"express": "^4.17.1",
"husky": "^1.0.1",
"jest": "^23.6.0",
"jest-config": "^23.6.0",
"lint-staged": "^8.0.0",
"lodash.camelcase": "^4.3.0",
"prettier": "^1.14.3",
"prompt": "^1.0.0",
"replace-in-file": "^3.4.2",
"rimraf": "^2.6.2",
"rollup": "^0.67.0",
"rollup-plugin-commonjs": "^9.1.8",
"rollup-plugin-json": "^3.1.0",
"rollup-plugin-node-resolve": "^3.4.0",
"rollup-plugin-sourcemaps": "^0.4.2",
"rollup-plugin-typescript2": "^0.18.0",
"semantic-release": "^15.9.16",
"shelljs": "^0.8.3",
"travis-deploy-once": "^5.0.9",
"ts-jest": "^23.10.2",
"ts-loader": "^6.1.1",
"ts-node": "^7.0.1",
"tslint": "^5.11.0",
"tslint-config-prettier": "^1.15.0",
"tslint-config-standard": "^8.0.1",
"tslint-loader": "^3.5.4",
"typedoc": "^0.12.0",
"typescript": "^3.0.3",
"webpack": "^4.40.2",
"webpack-dev-middleware": "^3.7.1",
"webpack-hot-middleware": "^2.25.0"
}
}
наконец
Вы можете обратить внимание на мой одноименный паблик [Front-end Forest], где я буду регулярно публиковать несколько актуальных статей, связанных с большим фронт-эндом, и практические выводы в ежедневном процессе разработки. Конечно, я также являюсь активным участником сообщества открытого исходного кода, адрес github — https://github.com/Jack-cool, добро пожаловать, звезда! ! !