| 
 | 1 | +Azure Notification Hubs for Java SDK Contributing Guide  | 
 | 2 | +-------------------------------------  | 
 | 3 | + | 
 | 4 | +Thank you for your interest in contributing to Azure Notification Hubs for Java SDK C.  | 
 | 5 | + | 
 | 6 | +- For reporting bugs, requesting features, or asking for support, please file an issue in the [issues](https://github.com/Azure/azure-sdk-for-java/issues) section of the project.  | 
 | 7 | + | 
 | 8 | +- If you would like to become an active contributor to this project please follow the instructions provided in [Microsoft Azure Projects Contribution Guidelines](http://azure.github.com/guidelines.html).  | 
 | 9 | + | 
 | 10 | +- To make code changes, or contribute something new, please follow the [GitHub Forks / Pull requests model](https://help.github.com/articles/fork-a-repo/): Fork the repo, make the change and propose it back by submitting a pull request.  | 
 | 11 | + | 
 | 12 | +Pull Requests  | 
 | 13 | +-------------  | 
 | 14 | + | 
 | 15 | +- **DO** submit all code changes via pull requests (PRs) rather than through a direct commit. PRs will be reviewed and potentially merged by the repo maintainers after a peer review that includes at least one maintainer.  | 
 | 16 | +- **DO NOT** submit "work in progress" PRs.  A PR should only be submitted when it is considered ready for review and subsequent merging by the contributor.  | 
 | 17 | +- **DO** give PRs short-but-descriptive names (e.g. "Improve code coverage for Azure.Core by 10%", not "Fix #1234")  | 
 | 18 | +- **DO** refer to any relevant issues, and include [keywords](https://help.github.com/articles/closing-issues-via-commit-messages/) that automatically close issues when the PR is merged.  | 
 | 19 | +- **DO** tag any users that should know about and/or review the change.  | 
 | 20 | +- **DO** ensure each commit successfully builds.  The entire PR must pass all tests in the Continuous Integration (CI) system before it'll be merged.  | 
 | 21 | +- **DO** address PR feedback in an additional commit(s) rather than amending the existing commits, and only rebase/squash them when necessary.  This makes it easier for reviewers to track changes.  | 
 | 22 | +- **DO** assume that ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) will be used to merge your commit unless you request otherwise in the PR.  | 
 | 23 | +- **DO NOT** fix merge conflicts using a merge commit. Prefer `git rebase`.  | 
 | 24 | +- **DO NOT** mix independent, unrelated changes in one PR. Separate real product/test code changes from larger code formatting/dead code removal changes. Separate unrelated fixes into separate PRs, especially if they are in different assemblies.  | 
 | 25 | + | 
 | 26 | +Merging Pull Requests (for project contributors with write access)  | 
 | 27 | +----------------------------------------------------------  | 
 | 28 | + | 
 | 29 | +- **DO** use ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) by default for individual contributions unless requested by the PR author.  | 
 | 30 | +  Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit".  | 
 | 31 | +  Reasons that PR authors may request "Merge and Commit" may include (but are not limited to):  | 
 | 32 | + | 
 | 33 | +  - The change is easier to understand as a series of focused commits. Each commit in the series must be buildable so as not to break `git bisect`.  | 
 | 34 | +  - Contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash  | 
 | 35 | +    the commits manually before acceptance.  | 
0 commit comments