> For the complete documentation index, see [llms.txt](https://docs.cherryai.com.cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cherryai.com.cn/docs/russian/contribution/code.md).

# Внести вклад в код

Вклад в код начинается с чёткой проблемы. Перед исправлением дефекта сначала убедитесь, что его можно воспроизвести; перед добавлением функции сначала опишите сценарий пользователя и ожидаемое поведение. Для крупных изменений рекомендуется сначала согласовать направление в GitHub Issue или Discussion.

<figure><img src="https://3765361039-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0Ut5BptC3t8CtSU1UWpM%2Fuploads%2FcMEZnURLllvPJjbTjF31%2Fclipboard.png?alt=media&amp;token=2ebd2302-01ea-4d15-81ce-62fa878c4894" alt="从说明问题、最小改动、本地验证到提交评审和合并的贡献流程图"><figcaption><p>Один вклад решает только одну чёткую проблему; сначала выполните локальную проверку, затем отправляйте на ревью.</p></figcaption></figure>

## Перед началом

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Репозиторий Cherry Studio</strong></td><td>Исходный код, README и вход для разработки</td><td><a href="https://github.com/CherryHQ/cherry-studio">https://github.com/CherryHQ/cherry-studio</a></td></tr><tr><td><strong>GitHub Issues</strong></td><td>Дефекты, предложения функций и вопросы, требующие решения</td><td><a href="https://github.com/CherryHQ/cherry-studio/issues">https://github.com/CherryHQ/cherry-studio/issues</a></td></tr><tr><td><strong>Руководство по вкладу</strong></td><td>Требования к веткам, тестированию, подписанию и ревью</td><td><a href="https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md">https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md</a></td></tr><tr><td><strong>Кодекс поведения</strong></td><td>Границы сотрудничества в сообществе</td><td><a href="https://github.com/CherryHQ/cherry-studio/blob/main/CODE_OF_CONDUCT.md">https://github.com/CherryHQ/cherry-studio/blob/main/CODE_OF_CONDUCT.md</a></td></tr></tbody></table>

Подходящие для начала задачи можно найти по `good first issue`、`help wanted` и `kind/bug` в виде меток. Перед тем как начать, напишите в Issue, что именно вы собираетесь делать, чтобы избежать дублирования работы несколькими людьми.

## Какую ветку выбрать

Большинство текущих функций, исправлений, рефакторинга и оптимизаций отправляются в `main`. Если Issue, указания сопровождающих или руководство по вкладу указывают другую целевую ветку, ориентируйтесь на описание проекта на тот момент; не судите только по старым инструкциям.

{% hint style="warning" %}
Не определяйте целевую ветку по старым инструкциям. Перед созданием PR ещё раз проверьте текущее руководство по вкладу и шаблон PR в репозитории; если политика веток изменилась, ориентируйтесь на содержимое репозитория.
{% endhint %}

## Когда подходит вклад в код

| Ситуация                                                     | Рекомендуемый способ                                                       |
| ------------------------------------------------------------ | -------------------------------------------------------------------------- |
| Проблемы, которые стабильно воспроизводятся                  | Сначала отправьте минимальное исправление и соответствующую проверку       |
| Небольшие функции с чёткими границами                        | Сначала подтвердите требования и целевую ветку, затем начинайте реализацию |
| Связано с миграцией данных, правами доступа или архитектурой | Сначала согласуйте решение в Issue или Discussion                          |
| Нужно только изменить документацию или скриншоты             | Идите по пути【вклад в документацию】, не смешивайте это с кодовым PR        |

{% hint style="info" %}
Один PR решает только одну чёткую проблему. Если изменения одновременно включают функциональность, рефакторинг и несвязанное форматирование, ревьюеру сложно оценить риск, а откатить такие изменения ещё труднее.
{% endhint %}

## Процесс отправки

{% stepper %}
{% step %}

### 1. Сделайте fork и создайте ветку

Создайте рабочую ветку с чётким объёмом работ от правильной целевой ветки. Один PR решает только одну тему, не смешивайте в него попутный рефакторинг и изменения форматирования.
{% endstep %}

{% step %}

### 2. Подготовьте среду разработки

Следуя 【Developer Guide】 репозитория, установите указанные версии Node.js и pnpm, выполните `pnpm install`. Перед началом изменений сначала запустите существующие проверки, относящиеся к целевому модулю, чтобы убедиться, что базовое состояние работоспособно.
{% endstep %}

{% step %}

### 3. Измените и проверьте

Исправления дефектов должны включать тест, воспроизводящий проблему; новые функции должны покрывать ключевой путь и сценарии отказа. Перед отправкой выполните требуемые репозиторием проверки форматирования, статического анализа, тесты и сборку.
{% endstep %}

{% step %}

### 4. Сделайте коммит и подпишите

В сообщении коммита укажите тип изменения и модуль, и используйте `git commit --signoff` для добавления DCO-подписи. Подпись означает, что вы имеете право отправлять этот материал в соответствии с лицензией проекта.
{% endstep %}

{% step %}

### 5. Создайте PR

Заполните шаблон: что изменилось до и после, почему выбран именно такой подход, компромиссы и альтернативы, потенциально ломающие изменения, способ проверки и Release Note. Изменения, которые ещё требуют обсуждения, можно сначала оформить как Draft PR.
{% endstep %}
{% endstepper %}

## После отправки PR

PR от новых участников сначала будут иметь `needs-ok-to-test`, и автоматические тесты не начнутся сразу. После подтверждения участником репозитория будет использован `/ok-to-test` для запуска pipeline. Draft PR не назначается на обычное ревью и также пропускает автоматические тесты; когда всё готово, отметьте его как Ready for review.

Комментарии по ревью следует исправлять новыми коммитами, сохраняя контекст обсуждения. При расхождении в дизайне сначала возвращайтесь к пользовательской проблеме и проверяемому поведению, не переписывайте всё в широком объёме, чтобы избежать одного локального вопроса.

## Самопроверка перед отправкой

* Целевая ветка верна;
* Объём изменений соответствует описанию в Issue/PR;
* Для нового поведения есть тесты или воспроизводимые шаги ручной проверки;
* Пользовательские изменения синхронно отражены в документации;
* Учтены миграция данных, обновление и совместимость;
* Не были отправлены API Key, реальные данные пользователей или файлы отладки;
* Коммит подписан, Release Note соответствует требованиям шаблона.

<details>

<summary>Нужен ли Issue даже для небольших изменений?</summary>

Опечатки и очевидные мелкие исправления можно отправлять напрямую; если речь идёт о поведении продукта, архитектуре или более значительном объёме работы, сначала лучше открыть Issue, чтобы согласовать направление. Нужен ли Issue, определяется текущими правилами сопровождения репозитория.

</details>

<details>

<summary>Почему CI не запустился автоматически?</summary>

Сначала убедитесь, что PR не в состоянии Draft. Для PR от новых участников требуется, чтобы участник репозитория `/ok-to-test`, увидев `needs-ok-to-test` , терпеливо дождался подтверждения в PR.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cherryai.com.cn/docs/russian/contribution/code.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.