-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Instructions for Maintainers
Also applies to changes without PRs.
Optional: ensure origin looks like this in .git/config. The key element here is the second fetch statement
[remote "origin"]
url = git@github.com:dc-js/dc.js.git
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
2019 update: a better way to do this is to add the contributor's fork as a remote. The advantage is the ability to push the changes back after they have been rebased (if the contributor so allowed). This rewrites the PR and their branch and reflects as a merge in the GitHub UI, with the correct commits.
We use the git-flow workflow to support two active versions at once - see Development Branches for details. The AVH Edition of git-flow is really helpful.
Please follow these steps rigorously when tagging a new version.
You'll need to decide whether you will merge the change as a hotfix (to master), or as a feature (to develop).
-
npm update(update node modules that may be pulled intoweb/) - Change version in package.json
grunt docs-
grunt testorgrunt ci - (v3 and earlier and special npm branches only) Check in artifacts
- Add entries to Changelog.md
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. git-flow (at least the avh version) does not allow multiple hotfix branches open at once.
git flow hotfix start <tag>
git merge origin/pr/###
Fix stuff, make sure there are tests and if this is a bugfix, verify that the tests fail before the PR.
git flow hotfix finish <tag>
This will do all the merges, and you may have to work the mergetool a few times.
If you're working on a pre-4 version, you will get a bunch of merge conflicts at this point due to all the artifacts. Skip the artifacts for v4+ releases!
Get a list of conflicts with git status
First, look for the conflicts that are not artifacts. Build artifacts include dc.*js*, web/docs/*, web/js/*. Ignore those for now.
For any that you want to keep as it was, for example (usually, but think about it), package.json:
git checkout --ours package.json
git add package.json
(Or --theirs if you want to take the change made to master.)
http://gitready.com/advanced/2009/02/25/keep-either-file-in-merge-conflicts.html
For any that you want to merge, for example (usually), Changelog.md:
git mergetool Changelog.md
Now generate all the artifacts
grunt
grunt docs
Add all of them (warning: this is powerful, you should test again before to make sure everything has been generated):
git add dc.*js dc.*map web/docs/*.* web/js/*
And commit - if the commit hooks are enabled, this will fail if there are unresolved merge conflicts, or linting problems.
git commit -m "message"
git checkout develop; git push
git checkout master; git push
git push --tags
Now: wait for Travis to validate the changes. If it fails, you will have to tag a new version, so it's important not to publish to npm until we know it's good.
To avoid this uncertainty, test in various browsers using
grunt server
and navigate to http://127.0.0.1:8888/spec/
Finally, if Travis says it's okay:
npm publish
cdnjs will pick it up automatically.
The website follows master, so it needs to be updated after each hotfix or release.
git checkout mastergit push- Wait for Travis tests to cycle!
-
git diff origin/gh-pages master:web(review changes before site deployment) grunt web
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