PicGo BumpVersion
A full git commit
-> changelog
-> release
workflow & convention.
It's now only available for Node.js projects. Thanks standard-version for the inspiration.
Installation
npm install -D @picgo/bump-version conventional-changelog commitizen cz-customizable @commitlint/cli husky
yarn add -D @picgo/bump-version conventional-changelog commitizen cz-customizable @commitlint/cli husky
alternatively add the following things in your package.json
:
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"config": {
"commitizen": {
"path": "./node_modules/cz-customizable"
},
"cz-customizable": {
"config": "./node_modules/@picgo/bump-version/.cz-config.js"
},
},
"commitlint": {
"extends": ["./node_modules/@picgo/bump-verison/commitlint-picgo"]
}
And then add npm run scripts to your package.json:
"scripts": {
"cz": "git-cz",
"release": "bump-version"
}
Then you can use npm run cz
for commiting valid message && use npm run release
to bump version & auto generate changelog in your project!
If you are using yarn, then it will be more simple just like:
yarn cz
yarn release
So the workflow is the following:
git add
something changednpm run cz
to commitnpm run release
to release or deploy
Usage
If you install bump-version in project, then you can just write down the bump-version
command in your package.json
's scripts
field. Then just npm run you-command
.
Usage
bump-version
Example
bump-version -t major
Options
-a, --preid-alpha Prerelease id: alpha. Exp. 1.0.0.alpha-0
-b, --preid-beta Prerelease id: beta. Exp. 1.0.0.beta-0
-d, --dry Run bump version without change anything & output the log in console
-f, --file Read and write the CHANGELOG file, relative to package.json's path
Default: CHANGELOG.md
-p, --path A filepath of where your package.json is located
Default: ./
-h, --help Display help message
-t, --type Release type. [major, minor, patch, premajor, preminor, prepatch, prerelease]
Default: patch
--push Auto push commits to origin master
Default: false
--no-tag Tag won't be created
Default: tag will be created
--no-changelog Changelog won't be created
Default: changelog will be created
Don't know which version should be the next? Never mind:
If you reject the default next version, then you can choose which version you want or customize one.
if you just want to see what the changelog will be created and nothing will be changed:
npm run release --dry
Badges
Let more people know that you are using PicGo bump-version for elegant workflow!
[![PicGo Convention](https://img.shields.io/badge/picgo-convention-blue.svg?style=flat-square)](https://github.com/PicGo/bump-version)
PicGo Convention
PicGo's commit message guidelines.
Git Commit Message
-
Use the present tense ("add feature" not "added feature")
-
Use the imperative mood ("move cursor to..." not "moves cursor to...")
-
Do not repeat the word in type ("Fix: xxx bugs when..." not "Fix: fix xxx bugs when...")
-
Limit the first line to 72 characters or less
-
Start the commit message with an applicable emoji & type:
- :sparkles: Feature
:sparkles: Feature
when adding new features - :bug: Fix
:bug: Fix
when fixing bugs - :construction: WIP
:construction: WIP
when working in progress - :hammer: Refactor
:hammer: Refactor
when changing the code without adding features or fixing bugs - :package: Chore
:package: Chore
when changing the build process or auxiliary tools and libraries such as documentation generation - :art: Style
:art: Style
when improving the format/structure of the code - :arrow_up: Upgrade
:arrow_up: Upgrade
when upgrading dependencies - :zap: Perf
:zap: Perf
when improving performance - :pencil: Docs
:pencil: Docs
when wrting docs - :white_check_mark: Test
:white_check_mark: Test
when adding or updating tests - :back: Revert
:back: Revert
when reverting some commits - :pushpin: Init
:pushpin: Init
when initializing a project - :tada: Release
:tada: Release
when releasing (will be automatically committed by bump-version
)
Commit Message Format
A commit message consists of a header, body(optional) and footer(optional). The header has a emoji, type, scope(optional) and subject:
<emoji> <type>([scope]): <subject>
<BLANK LINE>
[body]
<BLANK LINE>
[footer]
Examples
1. Normal
:sparkles: Feature(core): add error notification
:bug: Fix(core): xxx error should be thrown
:sparkles: Feature(core): add error notification
:bug: Fix(core): xxx error should be thrown
and they will be rendered into the following changelog:
# x.x.0 (20xx-xx-xx)
## :sparkles: Features
- add error notification
## :bug: Bug Fixes
- xxx error should be thrown
2. BREAKING CHANGE
Note: BREAKING CHANGE can only be in the type of Feature
or Fix
.
:sparkles: Feature(core): add error notification
BREAKING CHANGE: change api for error notification
:sparkles: Feature(core): add error notification
BREAKING CHANGE: change api for error notification
and they will be rendered into the following changelog:
# x.x.0 (20xx-xx-xx)
## :sparkles: Features
- add error notification
## BEAKING CHANGES
- change api for error notification
Git Branch Management
Important: Always use rebase
or squash
or cherry-pick
instead of merge
Available branches:
master
for the releasedev
for the developmentalpha
for developing the next breaking change or next major releasedocs
or gh-pages
for the documentationpr
for the pull request [optional]hot-fix
for fixing the bug in master [optional]
License
MIT
Copyright (c) 2019 Molunerfinn