coffeelint-config-marviq
v1.0.2
Published
Marviq's shareable coffeelint config baseline.
Downloads
3
Maintainers
Readme
coffeelint-config-marviq
Marviq's shareable coffeelint config baseline.
Contributing
Prerequisites
Clone this repository somewhere, switch to it, then:
$ git config commit.template ./.gitmessage
$ git flow init -d
$ npm install
Branching Model
This project uses git flow
. Here's a quick cheat sheet.
Commit Message Format Discipline
This project uses conventional-changelog/standard-version
for automatic versioning and
CHANGELOG management.
To make this work, please ensure that your commit messages adhere to the
Commit Message Format. Setting your git config
to
have the commit.template
as referenced below will help you with a detailed reminder of how to do this on every git commit
.
$ git config commit.template ./.gitmessage
Releasing
Determine what your next semver
<version>
should be:$ version="<version>"
Create and checkout a
release/v<version>
branch off ofdevelop
:$ git flow release start "v${version}"
Bump the package's
.version
, update the CHANGELOG, commit these, and tag the commit asv<version>
:$ npm run release
If all is well this new
version
should be identical to your intended<version>
:$ jq ".version == \"${version}\"" package.json
If this is not the case, then either you assumptions about what changed are wrong, or (at least) one of your commits did not adhere to the Commit Message Format Discipline; Abort the release, and sort it out first.
Merge
release/v<version>
back into bothdevelop
andmaster
:$ git flow release finish -n "v${version}"
Note that contrary to vanilla git flow, the merge commit into
master
will not have been tagged (that's what the-n
was for). This is done becausenpm run release
has already tagged its own commit.I believe that in practice, this won't make a difference for the use of git flow; and doing it the other way round would render the use of conventional-changelog impossible.
Done.