These principles apply for any code merging request into the main source tree. Proposals provided by other means will not be accepted and the code will not be merged.

Commit message rules

All commit messages have to be written in English. Slovak or other language will result in pull request rejection.
Commit message has to consist of two parts: Short message heading and detailed description. Heading has to be brief (no more than 80 characters) and outline commit's content and functionality. This is very important as those headings create foundation for the Release notes construction and may be handed over directly to customer.
If commit realize a pivotal story or bug you have to follow [https://github.com/sosik/registries/wiki/Commiting-Fixed-bugs-and-Finished-stories]. Commit message's body can be written as bullet list or verbose textual message. In case of bullet list each line has to start by '-' and sentence has to start by lower case letter. There has to be none dot at the end of sentence.
In case of non bullet list message it has to start with upper case letter and end by dot.

Example of bullet list commit message:

[#73604414] Added player fields into person schema

- added field License number
- added field Valid to
- updated type of field Age to number

Example of non bullet list commit message:

[FINISHED #73604414] Menu elements hiding by permission presence

Menu elements are shown only if user has assigned particular security permission.
Required permission for menu element is defined in router configuration.
Permission is assigned to user by common means.

Commit rules

Each commit should be build-able and all tests should pass. Run grunt before commit.
Be clever in committing. Do not create unnecessary small commits. Commits are points in history of your code. Create commit when it makes sense to revert to this commit, commit creates integrated code block or implements particular feature, bug fix or functionality. In ideal scenario when someone creates cherry pick or omits particular commit, system should be stable enough and work.
This is rule of thumb and you should use common sense when committing.

Code submission process

When you are ready with implementation of some feature or block of functionality and you want to merge it into the main source tree, follow this process.

Create separate branch

When you start work on particular functionality or start to implement pivotal story create separate branch please. We all have to switch between tasks often and branches will help us to not mess different features in between. This applies especially to bug fixes. See documentation for git branch command or documentation for your favorite git gui.
When you accidentally mix several independent features or bugfixes we may reject your pull request and make cherry pick of single commit. This will force you to do a lot of git magic and add you additional unnecessary work.

Commit you work

As you implement feature of bug fix be clever what you commit. See Commit rules and Commit message rules.
You can do what ever you want in your repository. But when you want to merge your code into the main tree you should do some cleanup. See documentation for interactive rebase git rebase -i. You can reorganize you commits, merge or split them and adjust commit messages to follow defined rules.
Tests should be part of functional commit and should not be committed in separate one.

Please do not forged to test your code before commit. Commits should be build-able, tested and working.

Rebase your code on top of common root

To make code merging process easier, please, rebase your code on top of branch you want to merge into.

Create pull request

When you feel you are ready for merge, create pull request. See github documentation on pull requests.

Pull request has to:

• be rebased to HEAD of branch you want to merge into
• pass automated build and test
• follow coding rules (when defined)
• have sufficient test coverage (when defined)

Your pull request will be reviewed, tested, etc. If there are any issues preventing merge you will be noticed by code review comments, so please follow your pull request for activity. When all issues are fixed pull request will be merged into main tree and closed. When there is too much issues with pull request it can be rejected and you should create new pull request with fixed issues.