diff --git a/docs/ci_cd_workflow.md b/docs/ci_cd_workflow.md
new file mode 100644
index 0000000..0a66781
--- /dev/null
+++ b/docs/ci_cd_workflow.md
@@ -0,0 +1,40 @@
+# Настройка CI/CD и рабочий процесс (Workflow)
+
+## Общее описание
+В проекте настроен непрерывный процесс интеграции (CI) с использованием GitHub Actions.
+Конфигурация CI находится в файле `.github/workflows/ci.yml`.
+
+## Ветвление
+В репозитории используются две основные ветки:
+1. **`dev` (development)** — ветка для разработки и тестирования новых функций. Все новые наработки отправляются сюда.
+2. **`master`** — основная, стабильная ветка. Сюда попадает только проверенный и протестированный код из ветки `dev`.
+
+## Рабочий процесс (Workflow)
+Для того чтобы код попал в `master`, вам нужно следовать такому алгоритму:
+
+1. **Разработка:** Вы пишете код и делаете коммиты в вашу локальную ветку (или сразу в `dev`, если работаете с ней напрямую).
+2. **Отправка (Push) в `dev`:** При выполнении `git push` в ветку `dev`, GitHub Actions автоматически запускает тесты.
+   - Тесты запускаются в среде Ubuntu.
+   - Настраивается Python 3.12, устанавливаются необходимые пакеты и зависимости из `requirements.txt` (очищенного от Windows-специфичных пакетов).
+   - Выполняется команда для запуска тестов с использованием `pytest` (с фиктивными данными для БД и в виртуальном X-сервере `xvfb`).
+3. **Проверка (CI):**
+   - **Если тесты не прошли:** вы получите уведомление (крестик в GitHub). В этом случае нужно зайти во вкладку *Actions* в репозитории, посмотреть логи ошибки, исправить баг в коде и сделать новый коммит в `dev`.
+   - **Если тесты прошли успешно:** появится зеленая галочка.
+4. **Pull Request (PR):** Убедившись, что в `dev` все работает исправно (и CI светится зеленым), вы создаете Pull Request из ветки `dev` в ветку `master`.
+   - При создании PR в `master` снова автоматически запустятся тесты (согласно конфигурации `on: pull_request: branches: [master]`).
+5. **Слияние (Merge):** Если тесты в PR прошли успешно и код ревью пройден (если требуется), PR сливается в `master`.
+
+## Настройка защиты веток в GitHub (Branch Protection Rules)
+Чтобы процесс работал корректно и никто случайно не сломал `master`, необходимо в настройках репозитория на GitHub включить защиту веток:
+
+1. Перейдите в **Settings -> Branches**.
+2. В разделе **Branch protection rules** нажмите **Add rule** (или отредактируйте существующее для `master`).
+3. В поле **Branch name pattern** введите `master`.
+4. Включите следующие опции:
+   - **Require a pull request before merging:** Запрещает прямые коммиты в `master`. Все изменения должны проходить через PR (в нашем случае из `dev`).
+   - **Require status checks to pass before merging:**
+     - Выберите эту опцию и добавьте в список обязательных проверок джоб из нашего CI (он называется `test` согласно `ci.yml`).
+     - Включите **Require branches to be up to date before merging**.
+5. Сохраните изменения.
+
+Аналогичные правила можно настроить для ветки `dev` (например, чтобы код попадал в `dev` тоже через PR из feature-веток), но если вы коммитите прямо в `dev` один, то защиту для `dev` можно оставить менее строгой. Главное — защитить `master`.