Skip to content

Instructions for Maintainers

Gordon Woodhull edited this page Jan 12, 2015 · 31 revisions

Merging Pull Requests

Also applies to changes without PRs.

Ensure origin looks like this in .git/config. The key element here is the second fetch statement

[remote "origin"]
  url = [email protected]:dc-js/dc.js.git
  fetch = +refs/heads/*:refs/remotes/origin/*
  fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

As of January 2015, we use the git-flow workflow to support two active versions at once. An excellent introduction is here: http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/

First, decide whether you will merge the change as a hotfix (to master), or as a feature (to develop).

General build steps

Follow these rigorously when tagging a new version!

  1. npm update (update node modules that may be pulled into web/)
  2. Change version in package.json (if doing a hotfix)
  3. grunt docs
  4. grunt update-stock-example (if changing the version or making other changes you know will affect the stock example)
  5. grunt test && grunt test-browserify
  6. Check in artifacts
  7. Add entries to Changelog.md

Publish to the web (after each merge to develop, i.e. finishing a hotfix or feature)

  1. git push
  2. Wait for Travis tests to cycle!
  3. git diff origin/gh-pages master:web (review changes before site deployment)
  4. grunt web

Merge a hotfix

Every hotfix gets merged to master, tagged, and merged to develop. Usually the tag will be a version number, but names are also acceptable if you don't plan to make a release. It's not recommended to have multiple hotfix branches open at once, and not a good idea to publish/push hotfix branches to GitHub.

git flow hotfix start <tag>
git merge origin/pr/###

Fix stuff, make sure there are tests and (if relevant) that the tests fail before the PR.

git flow hotfix finish <tag>
git push --tags

This will do all the merges, and you may have to work the mergetool a few times.

Merge a feature

Feature branch names should be short but descriptive. It's acceptable to have many feature branches open at once (as long as you're happy with your mergetool). develop can always be merged to a feature branch. When a feature is ready, finish it to merge it back to develop. Feature branches can be published (pushed) back to GitHub.

git flow feature start <tag>
git merge origin/pr/###

Fix stuff, make sure there are tests and (if relevant) that the tests fail before the PR.

git flow feature finish <tag>

Merges to develop

git push