AderKonstantin/RobotFire
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source 
Signed-off-by: AderKonstantin <66168124+AderKonstantin@users.noreply.github.com>
This commit is contained in:
AderKonstantin 2024-12-09 12:01:26 +03:00 committed by GitHub
parent e7fe860936
commit f73d1288c7
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 28 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
CONTRIBUTING.md
View File

@ -1,21 +1,22 @@
# Code Style Guide to 'RobotFire' Repo
Обращаться к [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) и к [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html)
Не является обязательством, но было бы очень приятно🙂
Обращаться к [Conventional Commits](https://www.conventionalcommits.org/ru/v1.0.0/) и к [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html)
## <a name="rules"></a> Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you are working:
Чтобы обеспечить единообразие во всем исходном коде, помните об этих правилах во время работы:
* All features or bug fixes **must be tested** by one or more specs (unit-tests).
* All public API methods **must be documented**. (Details TBC).
* We follow [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html), but wrap all code at
* Все функции или исправления ошибок **должны быть протестированы** одной или несколькими спецификациями (unit-tests).
* Все публичные методы API **должны быть документированы(сопровождаться комментариями)**.
* Мы следуем [Google C# Style Guide](https://google.github.io/styleguide/csharp-style.html), но оберните весь код в
**100 characters**.
We have very precise rules over how our git commit messages can be formatted. This leads to **more
readable messages** that are easy to follow when looking through the **project history**. But also,
we use the git commit messages to **generate the Angular change log**.
У нас есть очень точные правила относительно того, как могут быть отформатированы наши сообщения коммита git. Это приводит к **более
читабельным сообщениям**, которые легко отслеживать при просмотре **истории проекта**. Но также,
мы используем сообщения коммита git для **генерации журнала изменений кода**.
### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The header has a special
format that includes a **type**, a **scope** and a **subject**:
Иметь сообщение к коммиту не обязательно.
Каждое сообщение о коммите состоит из **header**, **body** и **footer**. Заголовок имеет специальный формат, который включает **type**, **scope** и **subject**:
```
<type>(<scope>): <subject>
@ -25,14 +26,13 @@ format that includes a **type**, a **scope** and a **subject**:
<footer>
```
The **header** is mandatory and the **scope** of the header is optional.
**Header** обязателен, а **scope** заголовка необязательна.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
to read on GitHub as well as in various git tools.
Любая строка сообщения о коммите не может быть длиннее 100 символов! Это позволяет упростить чтение сообщения на GitHub, а также в различных инструментах git.
The footer should contain a [closing reference to an issue](https://help.github.com/articles/closing-issues-via-commit-messages/) if any.
Нижний колонтитул должен содержать [закрывающую ссылку на проблему](https://help.github.com/articles/closing-issues-via-commit-messages/) если таковая имеется.
Samples: (even more [samples](https://github.com/angular/angular/commits/master))
[Примеры](https://github.com/angular/angular/commits/master)
```
docs(changelog): update changelog to beta.5
@ -43,18 +43,18 @@ fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need the latest of these.
```
### Revert
If the commit reverts a previous commit, it should begin with `revert: `, followed by the header of the reverted commit. In the body it should say: `This reverts commit <hash>.`, where the hash is the SHA of the commit being reverted.
### Revert / Отмена
Если коммит отменяет предыдущий коммит, он должен начинаться с `revert: `, за которым следует заголовок отменяемого коммита. В теле должно быть написано: `Это отменяет коммит <hash>.`, где хэш — это SHA отменяемого коммита.
### Type
Must be one of the following:
### Type / Тип
Должно быть одно из следующего:
* **build**: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
* **ci**: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
* **perf**: A code change that improves performance
* **refactor**: A code change that neither fixes a bug nor adds a feature
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
* **test**: Adding missing tests or correcting existing tests
* **build**: Изменения, влияющие на систему сборки или внешние зависимости(packages, etc).
* **ci**: Изменения в наших файлах конфигурации CI и скриптах (примеры областей: GitHub Actions, GitLab CI, Jenkins, etc).
* **docs**: Файлы документации.
* **feat**: Новая функция или изменения касательно функционала(в том числе геймплей).
* **fix**: Фиксы багов.
* **perf**: Изменение кода, повышающее производительность (но не добавляющий новый функционал).
* **refactor**: Изменение кода, которое не исправляет ошибку и не добавляет функцию.
* **style**: Изменения, не влияющие на смысл кода (пробелы, форматирование, пропущенные точки с запятой и т. д.).
* **test**: Добавление отсутствующих тестов или исправление существующих тестов.