Our Git workflow

How to contribute

Perhaps the semantic content of "Rebase on master, squash your commits and force-push the PR" is not immediately clear to you. This page is here to help.

TODO: Write the article

It is okay if this isn't very clear. The maintainers will help you format your PR or edit it for you.

Workflow notes for maintainers

• master is an authoritative branch that should only be modified by pull requests (modulo light touch ups from maintainers).
• Contributions are made by forking the main repository, doing some work on your own branch, and filing a pull request. Usually a PR should be directed to master. For complex upcoming features, we might have a special "staging" branch instead, and contributors should PR against that. Ideally your work should be on a topic branch so you are not tempted to create a foxtrot merge.
• Please never git pull master. In fact just don't even git pull. Pulling is awful, the command you are looking for is rebase.
• Merging into master should often be a squash commit and usually following a rebase if necessary. master should not be littered with unnecessary merge commits and unnecessary noise from private work. Exceptions: Merges are okay for new features or big changes. Commits which are of some significance do not have to be squashed. You can interactively select a subset of commits to squash with git rebase -i.

No merge bubbles! No foxtrots! :)