...
Keep pull requests targeted. For instance, if you’re fixing a bug, do not introduce a new feature or fix another bug. Only commit to a refactoring if you can do it while keeping the PR small and without touching parts of the codebase unrelated to your bug. If you are inclined to add one or more refactorings to a PR, you may also want to consult with other Samvera developers (see [communication guidelines(communication.md)) in advance of doing so.
Push branches up quickly for review. We have found that work sitting in unpushed branches for longer than a day or so is likely to cause frustration. It is better for the author of the code, and the reviewers of the code, to see it sooner so there’s time to provide feedback before a large commitment is made. If you are choosing between copying/pasting code to a snippet site like Gist and pushing your branch, please push your branch; it allows developers to review your code in the context of the codebase with its commit history.
...
When you are satisfied that the code you have written adequately addresses the issue you’re working on, and your test suite covers your changes and is green, it’s time to prepare your changes for a pull request. We recommend that you squash all of your commits down into a single commitcommits that are trivial changes/testing fixes down into the main commit but also show your work (multiple commits are OK to explain what you did).
Next, you’ll want to check that your branch is up to date with its parent branch (likely to be master); if you kept your PR small and targeted, you will find that this isn’t a difficult process. Make sure your code conforms to style guidelines and your test suite is green, and then push your branch and create a pull request.