Git rules

This page contains all rules pertaining to this repository. If you have no (or very little) experience with Git, it is highly recommended to read the following carefully, and do some practise beforehand.

Branches

While working on something, you should create your own branch. After it's all finished, you should merge your feature to main branch. Nee branches should be named using kebab-case format e.g. image-processing.

Commits

Remember to give your commits descriptive title. It is hard to figure out what is happening in a feature branch with commits like:

• fix
• test method
• changes

Instead, try to make the most important point of your changes e.g.

• Change method X to run in parallel
• Remove redundant variables from class X
• Improve readability of method X

Remember to start your commit message with a verb in imperative mode e.g. "Include" not "Including" or "Includes". Limit the message title to 50 characters!

If needed, include description in commit message. In general, it is just a longer version of commit message, but if the commit includes more changes which cannot be included in 50 character of the title, it is the perfect place for detailed info.

Merging to main

All PRs (pull requests) to product branch must be approved by at least one person and pass sanity tests. Reviewer should be able to understand what and why it was changed/added without asking the developer. If something is unclear or some mistakes were found, it should be communicated to the author and therefore fixed.

If your PR have one commit, you may apply fixes as normal commits and then squash all changes. But if your PR have multiply commits, you should amend proper commits. Please follow this tutorial if you don't know how to do it. After the reviewing process you can merge your changes. If your commits looks like e.g.: "add method", "fix", "fix" you should squash all commits to one. It is generally prefered to have one commit per PR, so keep in mind that it shouldn't be too long, not to mess up the review process.

Code review

During code reviewing other peoples' code, try to find pieces of code that are not obvious. You should be able to understand the code just by looking at it, not by reaching out to the author. After your code has been commented and you decided that it requires corrections, use git rebase to implement them. Don't create new commit with fixes!. If you have never used git rebase, I suggest you take a look at this tutorial. The most important thing is to use git push origin <branch> --force-with-lease when pushing fixes, so that pull request's history does not get messed up.