docs: complete russian platform tutorial with contributing rules

CONTRIBUTING.md

@@ -0,0 +1,19 @@
+# Правила участия в проекте (Contributing Guidelines)
+
+Мы рады любой помощи в развитии нашего открытого учебника! Чтобы процесс был удобным для всех, пожалуйста, следуйте этим простым правилам.
+
+## Как предложить изменения
+
+1. **Создайте Issue (Задачу):** Если вы нашли ошибку или хотите предложить новую главу, сначала создайте Issue. Опишите, что именно вы хотите изменить.
+2. **Форкните репозиторий (Fork):** Сделайте копию репозитория в свой аккаунт с помощью кнопки "Fork".
+3. **Создайте новую ветку:** Никогда не вносите изменения в `main`. Создайте ветку: `git checkout -b docs/new-chapter`.
+4. **Внесите изменения:** Убедитесь, что вы используете правильное форматирование Markdown и пишете на грамотном русском языке.
+5. **Сделайте коммит (Commit):** Сообщения коммитов пишите **строго на английском языке**, кратко и по делу. Пример: `docs: fix typo in introduction` или `feat: add chapter about SSH keys`.
+6. **Откройте Pull Request (PR):** Отправьте ваши изменения в наш главный репозиторий.
+
+## Стандарты оформления
+* Используйте заголовки для логического разделения текста.
+* Выделяйте системные команды обратными кавычками: `git status`.
+* Будьте вежливы при обсуждении кода коллег.
+
+Спасибо за ваш вклад в развитие open-source!

README.md

@@ -1,52 +1,20 @@
-# REXNET Platform Tutorial
+# 🚀 Универсальное руководство по работе с Git и Платформой
 
-Welcome to the official REXNET documentation! This guide will walk you through the standard procedures for managing projects, collaborating with your team, and maintaining high code quality across our infrastructure.
+Добро пожаловать в открытую Академию DevOps! Этот репозиторий создан для всех, кто хочет научиться правильно и безопасно работать с системами контроля версий (Gitea, GitHub, GitLab) по профессиональным корпоративным стандартам.
 
-## 1. Organizations and Teams
+## 📖 О чём этот учебник?
 
-In our ecosystem, work is organized into **Organizations**. An organization represents a specific department or product (e.g., `REXNET`). 
-Instead of personal repositories, all work should be created within the relevant Organization to ensure centralized control.
+Здесь собраны лучшие практики (Best Practices) управления кодом, которые используются в крупных IT-компаниях. Независимо от того, работаете ли вы над личным проектом или в составе большой команды, эти правила помогут избежать потери данных и конфликтов в коде.
 
-### Managing Access
-Access is strictly managed via **Teams** within the Organization:
-- **Owners:** Full administrative access to all repositories and settings.
-- **DevOps:** Access to infrastructure, CI/CD pipelines, and deployment configurations.
-- **Developers:** Read and Write access to source code repositories.
-- **QA:** Access to testing environments and issue tracking.
+## 🗂 Содержание
 
-**Rule of Thumb:** Never grant direct repository access to a specific user. Always add the user to the appropriate Team.
+1. **[Основы работы (Basics)](docs/01-basics.md)** — Как правильно настроить рабочее место, клонировать код и делать коммиты.
+2. **[Ветвление и GitFlow (Branching)](docs/02-branching.md)** — Почему нельзя пушить в `main` и как правильно создавать ветки.
+3. **[Pull Requests и Code Review (Слияние)](docs/03-pull-requests.md)** — Как передавать код на проверку и получать одобрение коллег.
 
-## 2. Repositories and Branches
+## 🤝 Как внести свой вклад?
 
-A Repository is where your project code lives. We enforce strict branch management to ensure stability across the platform.
-
-- **`main` branch**: The production-ready branch. Code in `main` should always be stable and deployable. Direct commits to `main` are restricted.
-- **Feature Branches**: When starting new work, always create a branch off from `main`. Name your branch descriptively: `feature/login-system` or `bugfix/api-crash`.
-
-## 3. Pull Requests and Code Review
-
-All code changes must go through a **Pull Request (PR)**. This is our standard for peer review and quality control.
-
-### How to Create a PR:
-1. Push your feature branch to the repository.
-2. Open a new Pull Request targeting the `main` branch.
-3. Write a clear description of what the PR does and link any related Issues.
-4. Request a review from at least one member of your team (e.g., a Tech-Lead).
-
-Code cannot be merged into `main` until it receives an approving review.
-
-## 4. Issue Tracking
-
-We use **Issues** to track bugs, upcoming tasks, and feature requests. 
-
-- **Creating an Issue:** Always use clear titles and select appropriate **Labels** (e.g., `bug`, `enhancement`, `urgent`).
-- **Milestones:** Group related issues into Milestones to track progress for specific releases or sprints.
-- **Closing Issues:** Once a Pull Request that resolves an Issue is merged, the Issue should be closed automatically by including "Fixes #ID" in the PR description.
-
-## 5. Reverting Changes
-
-If a bad commit makes it into `main`, **never delete the commit history** (do not use force push).
-Instead, use the platform's **Revert** feature. This creates a new, safe commit that undoes the changes of the bad commit, preserving the history and maintaining a clear audit trail.
+Мы открыты для сообщества! Если вы нашли ошибку, опечатку или хотите добавить новую полезную главу в этот учебник, пожалуйста, ознакомьтесь с нашими правилами в файле [CONTRIBUTING.md](CONTRIBUTING.md).
 
 ---
-*Maintained by the REXNET DevOps Team.*
+*Создано и поддерживается командой REXNET для всего open-source сообщества.*

docs/01-basics.md

@@ -0,0 +1,39 @@
+# Основы работы с Git
+
+Любая профессиональная разработка начинается с правильной настройки окружения. В этой главе мы рассмотрим базовые шаги.
+
+## 1. Первоначальная настройка
+
+После установки Git на ваш компьютер, обязательно представьтесь системе. Это нужно, чтобы каждый коммит был подписан вашим именем.
+
+В терминале выполните команды:
+```bash
+git config --global user.name "Ваше Имя"
+git config --global user.email "ваш@email.com"
+```
+
+## 2. Клонирование репозитория
+
+Чтобы начать работу над существующим проектом, его нужно скачать (склонировать) на ваш компьютер:
+```bash
+git clone https://ваша-платформа.com/organization/repo.git
+```
+
+## 3. Стандартный рабочий цикл
+
+Ваша ежедневная работа будет состоять из трёх базовых команд:
+
+1. **Проверка статуса:** Узнайте, какие файлы были изменены.
+   ```bash
+   git status
+   ```
+2. **Добавление файлов (Add):** Подготовьте изменённые файлы к сохранению.
+   ```bash
+   git add .
+   ```
+3. **Сохранение (Commit):** Сохраните изменения с понятным комментарием (на английском).
+   ```bash
+   git commit -m "feat: add user login page"
+   ```
+
+Переходите к следующей главе, чтобы узнать, почему нельзя сразу отправлять эти изменения на сервер в главную ветку!

docs/02-branching.md

@@ -0,0 +1,31 @@
+# Ветвление и стратегия GitFlow
+
+В профессиональной разработке **строго запрещено** вносить изменения напрямую в главную ветку (`main` или `master`). Главная ветка — это святая святых, там всегда должен лежать 100% рабочий код, готовый к выгрузке на боевые серверы.
+
+## Как правильно работать? (Feature Branches)
+
+Каждая новая задача (будь то исправление маленького бага или создание огромной новой функции) должна выполняться в отдельной изолированной ветке.
+
+### Шаг 1. Получение свежих данных
+Перед началом работы всегда обновляйте свою локальную версию `main`:
+```bash
+git checkout main
+git pull origin main
+```
+
+### Шаг 2. Создание новой ветки
+Создайте ветку под вашу задачу. Используйте понятные префиксы (`feature/`, `bugfix/`, `docs/`):
+```bash
+git checkout -b feature/new-payment-system
+```
+
+### Шаг 3. Работа
+Вносите изменения в код, делайте коммиты. Все ваши сохранения будут происходить только внутри этой изолированной ветки, никак не влияя на основной проект.
+
+### Шаг 4. Отправка ветки на сервер
+Когда работа закончена, отправьте вашу ветку на платформу:
+```bash
+git push origin feature/new-payment-system
+```
+
+После этого наступает этап слияния (Pull Request), который мы разберём в следующей главе.

docs/03-pull-requests.md

@@ -0,0 +1,22 @@
+# Pull Requests и Code Review (Проверка кода)
+
+Вы написали отличный код в своей ветке `feature/new-system` и отправили его на сервер. Что дальше? Дальше вы должны попросить коллег проверить вашу работу и перенести её в главную ветку `main`. Этот процесс называется **Pull Request (PR)**.
+
+## Правила создания Pull Request
+
+1. **Зайдите на платформу (Gitea/GitHub)** в ваш репозиторий.
+2. Система автоматически предложит вам создать Pull Request из вашей недавно отправленной ветки.
+3. **Опишите изменения:** Чётко напишите, какую проблему решает ваш код. Прикрепите скриншоты, если вы изменили дизайн (UI).
+4. **Назначьте проверяющих (Reviewers):** Выберите одного или нескольких старших разработчиков (Tech Leads), которые должны проверить ваш код.
+
+## Процесс Code Review
+
+* Проверяющий внимательно читает каждую строчку вашего кода.
+* Если есть ошибки или моменты для улучшения, он оставляет комментарии.
+* Вы исправляете ошибки на своём компьютере, делаете новые коммиты и снова отправляете их (`git push`). Pull Request обновится автоматически!
+
+## Слияние (Merge)
+
+В серьёзных организациях установлена **Защита веток (Branch Protection)**. Это означает, что кнопка слияния будет заблокирована до тех пор, пока проверяющий официально не нажмёт кнопку **Approve** (Одобрить).
+
+Только после получения аппрува код можно слить в `main`, и задача считается выполненной!