@@ -120,8 +120,6 @@ committing your changes. Most editors have plug-ins that do this automatically.

 Pull requests descriptions should be as clear as possible and include a

 reference to all the issues that they address.

-Pull requests must not contain commits from other users or branches.

-

 Commit messages must start with a capitalized and short summary (max. 50

 chars) written in the imperative, followed by an optional, more detailed

 explanatory text which is separated from the summary by an empty line.

@@ -132,6 +130,12 @@ sure to post a comment after pushing. The new commits will show up in the pull

 request automatically, but the reviewers will not be notified unless you

 comment.

+Pull requests must be cleanly rebased ontop of master without multiple branches

+mixed into the PR.

+

+**Git tip**: If your PR no longer merges cleanly, use `rebase master` in your

+feature branch to update your pull request rather than `merge master`.

+

 Before the pull request is merged, make sure that you squash your commits into

 logical units of work using `git rebase -i` and `git push -f`. After every

 commit the test suite should be passing. Include documentation changes in the