Workflow

If you're interested in contributing to Crafty, here is an outline of the workflow you should use:

• Fork Crafty on github.
• Clone the forked repo locally
• (Or, if you already have a local clone, pull any changes from upstream into develop)
• From the develop branch, create and checkout a new branch to work upon.
• Make your changes in that branch.
• Change are made to the individual files in the /src directory, not to crafty.js.
• If sensible, add some qunit tests in /tests/unit/!
• If sensible, add some webdriver tests in /tests/webdriver/!
• Check that your code works, and that there are no regressions!
• Run the unit tests and jshint with the command grunt check.
• Make sure any games you've been working on aren't unexpectedly broken by your changes
• Push the changes to your github repo
• Submit a pull request from your repo back to the original repository
• Once it is accepted, remember to pull those changes back into your develop branch!

If you're unfamiliar with git, these pages should help you! And there are a lot of great resources out there if you search for them.

• Github: Setting up git
• Github: Forking a repo
• Git Basics

Some tips

• If you're making large changes, you should let the community know! Either post on the forum or open an issue -- that'll help you get guidance and prevent duplicated effort.
• Each new feature should go in its own new branch, not on the develop branch. That lets you work on multiple features at once!
• A pull request on github is keyed to the branch, not a specific commit. So any further changes you make to the branch will show up on the pull request.
• Don't be afraid to change history when working solo, even after a pull request has been opened:
• There's no need for a branch's history to reflect any mistakes you've made along the way. A clean history is easier to read and understand. Think of each commit as a meaningful change to the code that can stand on its own (no wild "fixes bugABC in commitXYZ" commits in your commit history - rebase is your friend).
• If you make a mistake in your last commit, then git commit --amend is your friend.
• rebase can do many things -- squashing multiple commits to one, reordering commits, etc.
• But don't alter history in your public repo if someone else is working off that branch

Squashing commits

For a more complete tutorial read Rewriting History. Quick example of how to squash multiple commits into one, on a feature branch:

git checkout <name of your feature branch>
git rebase -i <put the first letters of the revision just before your first commit here>
<pick the first commit, squash the following commits in the editor that comes up, save & exit editor>
<consolidate all messages into one meaningful one in the 2nd editor that comes up, save & exit editor>
git push --force <this command overwrites the branch on your github repo with your local branch>