coffeelint-config-marviq
v1.0.2
Published
Marviq's shareable coffeelint config baseline.
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 installBranching 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 ./.gitmessageReleasing
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 releaseIf all is well this new
versionshould be identical to your intended<version>:$ jq ".version == \"${version}\"" package.jsonIf 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 bothdevelopandmaster:$ git flow release finish -n "v${version}"Note that contrary to vanilla git flow, the merge commit into
masterwill not have been tagged (that's what the-nwas for). This is done becausenpm run releasehas 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.
