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 of develop:
```
$ git flow release start "v${version}"
```
Bump the package's .version, update the CHANGELOG, commit these, and tag the commit as v<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 both develop and master:
```
$ 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 because npm 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.

License

BSD-3-Clause

Usage no npm install needed!