1# How to contribute 2 3Contributions are always very much appreciated. However, to make sure the 4process of accepting patches goes smoothly for everyone (especially for 5the maintainer), you should try to follow these few simple guidelines when 6you contribute: 7 81. Fork the repository. 92. Create a new branch based on the `develop` branch (`git checkout -b your_branch develop`). 10 If your contribution is a bug fix, you should name your branch `bugfix/xxx`; 11 for a feature, it should be `feature/xxx`. Otherwise, just use your good 12 judgment. Consistent naming of branches is appreciated since it makes the 13 output of `git branch` easier to understand with a single glance. 143. Do your modifications on that branch. Except for special cases, your 15 contribution should include proper unit tests and documentation. Also, 16 please try to follow the style guide below. 174. Make sure your modifications did not break anything by building and 18 running the tests: 19 20 ```shell 21 mkdir build 22 cd build 23 cmake .. 24 cmake --build . --target check 25 ``` 265. Commit your changes. Your commit message should start with a one line 27 short description of the modifications, with the details and explanations 28 of your modifications following in subsequent paragraphs or bullet points. 29 Please limit your lines to about 78 characters in commit messages, since 30 it makes the output easier to read in `git log`. Also, starting your commit 31 message with a tag describing the nature of the commit is nice, since it 32 makes the commit history easier to skim through. For commits that do not 33 change any functionality (e.g. refactoring or fixing typos), the `[NFC]` 34 tag (No Functionality Change) can be used. Here's an example of an 35 acceptable commit message: 36 ``` 37 [Searchable] Refactor the interface 38 39 - Rename elem to contains 40 - Rename subset to is_subset, and make is_subset applicable in infix notation 41 - Add the at_key method 42 - operator[] is now bound to at_key instead of find 43 ``` 44 When applicable, please squash adjacent _wip_ commits into a single 45 _logical_ commit. If your contribution has several logical commits, 46 it's fine. 476. Push the changes to your fork (`git push origin your_branch`). 487. Open a pull request against Hana's `develop` branch (not against `master`). 49 I will do my best to respond in a timely manner. I might discuss your patch 50 and suggest some modifications, or I might amend your patch myself and ask 51 you for feedback. You will always be given proper credit. 52 53 54## Style guide 55 56I'm not going to write an exhaustive style guide, but here are a couple of 57points you should watch out for: 58- Indent using 4 spaces. 59- Do not leave trailing white spaces at the end of lines, and no more than a 60 single newline at the end of a source file. 61- Hana's `#include`s go first, then a blank line and system headers. 62 `#include`s within each block should be sorted in alphabetical order. 63- Use your own judgment and stick to the style of the surrounding code. 64