improvement(docs): add branch style

This reverts commit 46739aa601.

CONTRIBUTING.md

@@ -11,24 +11,39 @@ Each of these types is described in detail below.
 
 ## Issues
 
-You can help us by submitting issues about problems found in the system. Currently, there are two main ways of submitting an issue in the project: **Bug Reports** and **Feature Requests**:
+You can help us by submitting issues about problems found in the system.
+Currently, there are two main ways of submitting an issue in the project:
+**Bug Reports** and **Feature Requests**:
 
-- Bug Reports are suitable if you find a **bug** (crash, error, unexpected behavior) in some part of the system (kernel, drivers, apps, etc.) and want to report it
+- Bug Reports are suitable if you find a **bug** (crash, error, unexpected
-- Feature Request are used, when you want to propose some **improvement** to the system (missing features, improved  user experience, etc.)
+behavior) in some part of the system (kernel, drivers, apps, etc.) and want to
+report it
+- Feature Request are used, when you want to propose some **improvement** to
+the system (missing features, improved  user experience, etc.)
 
 ## Pull requests
 
-You can also help us by submitting code via pull requests. The process of submitting a pull request consists of the following steps:
+You can also help us by submitting code via pull requests. The process of
+submitting a pull request consists of the following steps:
 
 1. Find what you want to implement or improve
 2. Make a fork of kolibrios (or other needed) repository
-3. Create a branch with a name that matches your changes
+3. Create a branch with a name that matches [the style](#branch-style)
 4. Implement and test the changes
 5. Create commits according to the [accepted style](#commit-style)
 6. Create and submit a pull request into `main` branch
 7. Wait for CI/CD pipelines and code review to pass
 
-When a pull request is submitted, at least two project participants must conduct a code review, after which the proposed changes can be corrected (if it's necessary) and merged into the project.
+When a pull request is submitted, at least two project participants must conduct
+a code review, after which the proposed changes can be corrected (if it's
+necessary) and merged into the project.
+
+## Branch style
+
+1. Your branch name should be as short as possible, but describes your changes
+2. Words should be divided by minus sign (`-`)
+3. Optionally, might starts with general [type](#types) of your future PR
+with slash (`/`): `refactor/nasm-to-fasm`, `update/demos`, `fix/cp866-charset`
 
 ## Commit style
 
@@ -36,36 +51,68 @@ When a pull request is submitted, at least two project participants must conduct
 
 The commit message should look like this:
 
-```test
+```
-Commit message header
+type(scope): commit message header
 
 Commit message body, if needed
 ```
-
+- Use the present tense ("Add feature" not "Added feature")
+- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
+- Limit the first line to 72 characters or less
+- Reference issues and pull requests liberally after the first line
+- When only changing documentation, include [ci skip] in the commit title
 - Commit message header and body should reflect changes made in commit
-- Commit message body should be separated from the header by one empty line
 
-### Length
+### Types
 
-Maximum number of characters in a commit header is **72** (standard for **Git**). Also, **72** is the maximum length of a line in a commit body.
+|       Type       | Description                                       |
+| :--------------: | :------------------------------------------------ |
+| `feat / feature` | for new feature implementing commit               |
+|     `update`     | for update commit                                 |
+|      `bug`       | for bug fix commit                                |
+|    `security`    | for security issue fix commit                     |
+|  `performance`   | for performance issue fix commit                  |
+|  `improvement`   | for backwards-compatible enhancement commit       |
+|    `breaking`    | for backwards-incompatible enhancement commit     |
+|   `deprecated`   | for deprecated feature commit                     |
+|      `i18n`      | for i18n (internationalization) commit            |
+|      `a11y`      | for a11y (accessibility) commit                   |
+|    `refactor`    | for refactoring commit                            |
+|      `docs`      | for documentation commit                          |
+|    `example`     | for example code commit                           |
+|      `test`      | for testing commit                                |
+|      `deps`      | for dependencies upgrading or downgrading commit  |
+|     `config`     | for configuration commit                          |
+|     `build`      | for packaging or bundling commit                  |
+|    `release`     | for publishing commit                             |
+|      `wip`       | for work in progress commit                       |
+|     `chore`      | for other operations commit                       |
 
-### Multiple authors
+### Scopes
 
-If you are making a commit together with another developer, you need to add:
+> [!NOTE]
+> Scopes are optional
 
-```
+| Scope  | Description                      |
-Co-authored-by: ANOTHER-NAME <ANOTHER-NAME@EXAMPLE.COM>
+| :----: | :------------------------------- |
-```
+| `krn`  | kernel                           |
+| `drv`  | drivers                          |
+| `lib`  | libraries                        |
+| `app`  | userspace applications           |
+| `skin` | skins                            |
+| `data` | images, configs, resources, etc. |
 
-to the end commit message body on a new line.
+> [!NOTE]
+> If changes are made to a specific component, the name of the component
+> separated by `/` character needs to be specified. For example:
+> `app/shell`, `lib/libimg`
 
-### Merge commits
+## Merge commits
 
 > [!WARNING]
 > Merge commits are **prohibited** in the project
 
-Use **rebase** to keep your branch up to date.
-
 ## Conclusion
 
-We hope this small instructions will help you to get familiar  with KolibriOS contribution rules and inspire you to participate in the work of this project.
+We hope this small instructions will help you to get familiar  with KolibriOS
+contribution rules and inspire you to participate in the work of this project.

README.md

@@ -1,7 +1,7 @@
 # KolibriOS
 
 [![License](https://img.shields.io/badge/License-GPL%202.0-green)](./COPYING.TXT)
-[![Build system](https://git.kolibrios.org/KolibriOS/kolibrios/actions/workflows/build.yaml/badge.svg)](https://git.kolibrios.org/KolibriOS/kolibrios/actions)
+[![Build system](https://git.kolibrios.org/KolibriOS/kolibrios/actions/workflows/build.yaml/badge.svg)](https://git.kolibrios.org/KolibriOS/kolibrios/actions/workflows/build.yaml)
 
 KolibriOS is a hobby operating system for x86-compatible computers, which is currently being developed by a small teem of enthusiasts.
 
@@ -20,3 +20,9 @@ Common list of tasks, issues and enhancement proposals can be found on [this pag
 ## Special thanks
 
 The KolibriOS team expresses special thanks to the author of the 32-bit **MenuetOS**, [Ville Turjanmaa](https://www.menuetos.net/contact.htm). We also want to note that all **MenuetOS** copyrights have been preserved.
+
+## License
+
+Contents of this repository are licensed under the terms of **GNU GPL 2.0** unless otherwise specified.
+
+See [this](./COPYING.TXT) file for details.