Contributing guide

Branches

• A new develop branch for active development between releases. Pull requests and maintainer-driven additions happen on this branch.
• A new release branch is cut from develop for each release candidate. This is for code review, bugfixes, shoring up unit test coverage, etc. As a final step before release, this branch gets the version number bump.
• Once a release is complete, it is merged to master and the merge commit is tagged with the release version (e.g., v3.0.1). This tag is then merged to develop to backport any fixes created during the release process. The release branch is then safely deleted.
• As soon as master has been updated, the new module version should be published to npm.

Let's say a bunch of awesome new changes are in the works for igdb-api-node...

# Create the new develop branch from the current master
$ git checkout -b develop master
Switched to a new branch "develop"

The changes are made, tested out, seem to work. They're committed to develop. Time to cut a release!

# Create a new release branch from the current develop
$ git checkout -b release/v3.x.y develop
Switched to a new branch "release/v3.x.y"

The release is thoroughly tested, unit test coverage improved, contributions acknowledged, version bumped. Time to finish the release.

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release/v3.x.y
Merge made by recursive.
(Summary of changes)
$ git tag -a v3.x.y

The release is now done and tagged for future reference. To make sure the changes made in the release branch are preserved in develop, we need to merge them back.

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff v3.x.y # note that we're merging the tag, not the release branch itself
Merge made by recursive.
(Summary of changes)

Once this is done and any potential merge conflicts are resolved, we can get rid of the release branch since we don't need it anymore.

$ git branch -d release/v3.x.y
Deleted branch release/v3.x.y (was ff452fe)

NOTE: The tag is merged into develop and not the release branch itself because merging the branch would create a new merge commit on develop that does not match the hash of the earlier merge commit on master. Merging the tag preserves the order of commits between the two mainline branches and ensures there isn't a diverging history between them during the interval between releases.