-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Instructions for Maintainers
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).
Follow these rigorously when tagging a new version!
-
npm update(update node modules that may be pulled intoweb/) - Change version in package.json (if doing a hotfix)
grunt docs-
grunt update-stock-example(if changing the version or making other changes you know will affect the stock example) grunt test && grunt test-browserify- Check in artifacts
- Add entries to Changelog.md
git push- Wait for Travis tests to cycle!
-
git diff origin/gh-pages master:web(review changes before site deployment) grunt web
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.
Feature 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