# Contributing ## Contributing to the HiveMQ Community Projects Welcome to the HiveMQ Community! Glad to see your interest in contributing to HiveMQ MQTT Client. Please checkout our [Contribution Guide](https://github.com/hivemq/hivemq-community/blob/master/CONTRIBUTING.adoc) to make sure your contribution will be accepted by the HiveMQ team. For information on how the HiveMQ Community is organized and how contributions will be accepted please have a look at our [HiveMQ Community Repo](https://github.com/hivemq/hivemq-community). ## Contributing to HiveMQ MQTT Client ### External contributors If you would like to contribute code, do the following: - Fork the repository on GitHub - Open a pull request targeting the `develop` branch ### License By contributing your code, you agree to license your contribution under the terms of the [Apache License, Version 2.0](https://github.com/hivemq/hivemq-mqtt-client/blob/develop/LICENSE). All files must contain the license header from the [HEADER](https://github.com/hivemq/hivemq-mqtt-client/blob/develop/HEADER) file. ### Branching model - `master`: release branch, protected - `develop` is merged into `master` by creating a merge commit if a new version is released - The release is tagged with the version `vX.Y.Z` - `develop`: snapshot branch, protected - Contains features for the next release - Feature/bugfix/... branches are merged into `develop` by rebasing and merging - Every feature/bugfix/... will have its own branch - Branched off from `develop` - Pull request targeting the `develop` branch - Mandatory code review of the pull request - `gh-pages`: documentation branch, protected ### Branching guidelines - Branch types: feature, bugfix, improvement, cleanup (same as the label of a corresponding GitHub Issue) - Branch names: - Starting with type: `feature/`, `bugfix/`, `improvement/`, `cleanup/` - \+ task: lower case, spaces replaced with `-` ### Commit guidelines - Commits should be as atomic as possible. - Commit messages should describe the changes clearly. - Commit messages should start with a capital letter for consistency. - Commit messages should avoid exceeding the line length limit. Instead use multiple lines, each describing one specific change. ### Code style guidelines - The project uses Nullability annotations to avoid NullPointerExceptions: `@NotNull`, `@Nullable`. Every non-primitive parameter/return type/field should be annotated with one of them. - For IntelliJ IDEA the codeStyleConfig and the inspectionProfile are provided in the `.idea` folder.