Initial commit

docs/git.md

@@ -0,0 +1,638 @@
+# Git для авторов документов
+
+## Зачем он нужен
+
+Git хранит последовательность контрольных точек проекта. Он помогает:
+
+- увидеть, кто и зачем изменил текст;
+- вернуться к предыдущей версии;
+- работать над разделами параллельно;
+- объединять согласованные изменения;
+- не пересылать папки `Финал`, `Финал 2`, `Финал точно`.
+
+## Коммит
+
+Коммит похож на сохранённую контрольную точку с подписью. В него входят выбранные изменения и короткое объяснение.
+
+Хорошие сообщения:
+
+- `Добавлена глава о геологическом строении`;
+- `Уточнены выводы по замечаниям заказчика`;
+- `Обновлены рисунки раздела 3`.
+
+Один коммит должен описывать одну законченную мысль. Перед коммитом желательно собрать PDF.
+
+## Ветка
+
+Ветка — параллельная версия проекта. Основной документ остаётся стабильным, пока вы работаете над отдельной главой.
+
+Подходящие имена:
+
+- `chapter-geology`;
+- `review-comments`;
+- `update-figures`.
+
+Создание в VS Code: нажмите имя текущей ветки в строке состояния и выберите **Create new branch**.
+
+## Push и Pull
+
+- **Push** отправляет ваши коммиты на сервер.
+- **Pull** получает коммиты коллег.
+- **Sync Changes** обычно выполняет получение и отправку последовательно.
+
+Всегда выполняйте Pull перед началом работы и перед merge. Push нужен не только в конце дня: серверная копия защищает работу при поломке компьютера.
+
+## Merge
+
+Merge переносит результат одной ветки в другую.
+
+1. Завершите работу в своей ветке: проверка → commit → push.
+2. Переключитесь на целевую ветку, обычно `main`.
+3. Выполните Pull.
+4. Запустите `Git: Merge Branch` через `Ctrl+Shift+P`.
+5. Выберите рабочую ветку.
+6. Проверьте PDF, затем Push.
+
+## Конфликт
+
+Конфликт означает, что две ветки изменили одно и то же место по-разному. Это не поломка и не потеря данных.
+
+VS Code предлагает трёхсторонний редактор:
+
+- **Accept Current Change** — оставить только вариант Current;
+- **Accept Incoming Change** — оставить только вариант Incoming;
+- **Accept Both Changes** — поместить в результат оба варианта.
+
+`Accept Both` не гарантирует правильный результат. Например, в тексте могут одновременно остаться значения 28° и 31°. Итоговую область Result можно и нужно редактировать вручную, чтобы получить одну связную и достоверную формулировку.
+
+<!-- СКРИНШОТ 11: Merge Editor целиком. Подписать Incoming, Current, Result, флажки выбора и кнопку Complete Merge. Лучше использовать учебный конфликт в .typ. -->
+
+### 29. Завершить конфликт
+
+Для каждого конфликтующего файла:
+
+1. сформируйте правильный текст в Result;
+2. удалите повторы и проверьте синтаксис Typst;
+3. сохраните файл;
+4. нажмите **Завершить слияние (Complete Merge)**.
+
+Когда все файлы обработаны:
+
+1. вернитесь в Source Control;
+2. нажмите **Продолжить слияние (Continue Merge)** или создайте предложенный коммит слияния;
+3. соберите весь отчёт;
+4. проверьте нумерацию, ссылки, рисунки, таблицы, параметры и единицы измерения;
+5. выполните Sync в рабочей ветке.
+
+Успешное разрешение конфликта означает лишь, что Git больше не видит двух технических вариантов. Оно не доказывает, что инженерное содержание стало правильным. Проверка отчёта обязательна.
+
+Если Pull Request уже открыт, новый создавать не нужно. После Sync существующий Pull Request обновится.
+
+### 30. Если конфликт стал непонятным
+
+Не выбирайте варианты наугад только для того, чтобы убрать красные отметки.
+
+Если вы перестали понимать, какие ветки объединяются или какой текст должен остаться:
+
+1. не выполняйте Sync и не закрывайте задачу;
+2. нажмите `Ctrl+Shift+P`;
+3. выберите **Git: Abort Merge** — прервать слияние;
+4. проверьте ветки и исходные данные;
+5. повторите операцию вместе с ответственным автором.
+
+Abort Merge возвращает проект к состоянию перед началом Merge. Это нормальный способ остановить неудачное объединение.
+
+### 31. Как уменьшить количество конфликтов
+
+- Разделяйте главы по отдельным файлам в `chapters/`.
+- Закрепляйте за рабочей веткой одного ответственного.
+- Не редактируйте один абзац одновременно без договорённости.
+- Не переименовывайте и не перемещайте общие файлы во время параллельной работы без предупреждения команды.
+- Меняйте `main.typ` только при необходимости.
+- Начинайте задачу от свежего `main`.
+- Не держите готовую ветку неделями без Pull Request.
+- Регулярно делайте Commit и Sync.
+
+Git помогает объединить изменения, но не заменяет распределение ответственности за главы, параметры и выводы.
+
+---
+
+## Часть V. Переключение и история
+
+### 32. Перейти в другую ветку
+
+Перед переключением проверьте Source Control. Лучше, чтобы текущая работа была сохранена в коммите.
+
+Через VS Code:
+
+1. нажмите название ветки в нижнем левом углу;
+2. выберите нужную локальную ветку.
+
+Через Git Graph:
+
+1. нажмите правой кнопкой по локальной ветке;
+2. выберите **Checkout Branch**.
+
+Если VS Code не разрешает переключение из-за незакоммиченных изменений, не используйте Force Checkout и Discard Changes. Создайте коммит или временно примените Stash.
+
+### 33. Посмотреть ветку коллеги
+
+Если коллега опубликовал ветку, но вы её не видите:
+
+1. в Source Control откройте меню `…`;
+2. выберите **Получить (Fetch)**;
+3. откройте Git Graph;
+4. найдите, например, `origin/work/stability`;
+5. нажмите ветку правой кнопкой и выберите **Checkout Branch...**.
+
+Git создаст локальную ветку, связанную с серверной. Просматривайте и собирайте её, но не начинайте редактировать чужую ветку без согласования.
+
+Fetch получает сведения о новых ветках и коммитах, но сам не меняет открытые рабочие файлы.
+
+### 34. Посмотреть старую версию файла
+
+Если нужно узнать, как раньше был сформулирован вывод или когда изменилось число, не обязательно переключать весь проект.
+
+1. Откройте Git Graph.
+2. Нажмите нужный коммит.
+3. В списке изменённых файлов выберите файл.
+4. Используйте **View Diff** для сравнения или **View File at this Revision** для просмотра файла в той редакции.
+
+Это безопасный способ изучать историю: текущая ветка и рабочие файлы не переключаются.
+
+### 35. Перейти к старому коммиту целиком
+
+Такое переключение нужно редко, например чтобы собрать PDF старой редакции всего проекта.
+
+1. Убедитесь, что Source Control пуст.
+2. Откройте Git Graph.
+3. Найдите нужный коммит.
+4. Нажмите его правой кнопкой.
+5. Выберите **Checkout...**.
+
+После этого VS Code может показать состояние **Detached HEAD**. Оно означает, что вы смотрите конкретную историческую точку, а не обычную ветку.
+
+В Detached HEAD можно открывать файлы и собирать PDF. Не продолжайте там обычную работу и не создавайте новые коммиты. После просмотра нажмите название ветки внизу слева и вернитесь в `main` или рабочую ветку.
+
+Если нужно продолжить работу именно от старого коммита, сначала нажмите этот коммит в Git Graph правой кнопкой и выберите **Create Branch...**. Затем работайте в созданной ветке.
+
+### 36. Отменить уже опубликованную ошибку
+
+Если ошибочный коммит уже отправлен в Gitea, не удаляйте его из общей истории. Используйте **Revert** — новый коммит, который отменяет изменения выбранного.
+
+В Git Graph:
+
+1. найдите ошибочный коммит;
+2. нажмите его правой кнопкой;
+3. выберите **Revert...**;
+4. проверьте получившиеся изменения;
+5. соберите отчёт и выполните Sync.
+
+История останется понятной: в ней будет видно и первоначальное изменение, и его отмена. Для общей работы это безопаснее, чем Reset или Force Push.
+
+---
+
+## Часть VI. Rebase — только для отдельного случая
+
+### 37. Что делает Rebase
+
+**Rebase** переносит коммиты рабочей ветки на более свежую основу. Он может сделать историю ровнее, но технически создаёт новые версии перенесённых коммитов.
+
+До Rebase:
+
+```text
+A ── B ── E ── F       main
+     \
+      C ── D           work/geology
+```
+
+После Rebase рабочей ветки на `main`:
+
+```text
+A ── B ── E ── F       main
+                 \
+                  C' ── D'    work/geology
+```
+
+Коммиты `C'` и `D'` содержательно похожи на `C` и `D`, но имеют новую историю.
+
+Rebase **не объединяет рабочую ветку с `main`**. После него `main` не содержит вашу работу. Для завершения по-прежнему нужны Push, Pull Request, проверка и Merge в Gitea.
+
+### 38. Когда Rebase допустим
+
+Используйте Rebase только когда одновременно верны условия:
+
+- ветка принадлежит одному человеку;
+- никто другой не работает от её коммитов;
+- ветка ещё не опубликована или команда заранее согласовала переписывание;
+- Source Control пуст;
+- вы понимаете, что после Rebase старые и новые коммиты — разные.
+
+Для уже опубликованной рабочей ветки начинающей команде рекомендуется Merge `main` в рабочую ветку. Он не переписывает существующие коммиты и обычно не требует Force Push.
+
+### 39. Выполнить Rebase через Git Graph
+
+1. В рабочей ветке сохраните файлы, создайте коммиты и убедитесь, что Source Control пуст.
+2. Перейдите в `main` и выполните Sync.
+3. Вернитесь в рабочую ветку, например `work/geology`.
+4. Откройте Git Graph.
+5. Проверьте, что текущая ветка — `work/geology`.
+6. Нажмите правой кнопкой по **локальной ветке `main`**.
+7. Выберите **Rebase current branch on Branch...**.
+8. В окне подтверждения ещё раз проверьте смысл: текущая `work/geology` переносится на `main`.
+
+<!-- СКРИНШОТ 12: Git Graph перед Rebase. Выделить текущую work/geology, локальную main и команду Rebase current branch on Branch. Добавить подпись «переносим work/geology на main, не наоборот». -->
+
+Если конфликтов нет, Git перестроит ветку автоматически.
+
+Если возникает конфликт, Rebase останавливается на конкретном коммите. Разрешите конфликт в Merge Editor, проверьте Result и выберите **Continue Rebase**. Конфликт может повториться на следующем переносимом коммите — это нормально для Rebase.
+
+Во время Rebase особенно нельзя выбирать Current или Incoming только по названию. Читайте обе версии и итоговый Result.
+
+Если процесс стал непонятным: `Ctrl+Shift+P` → **Git: Abort Rebase**. Ветка вернётся к состоянию до начала Rebase.
+
+### 40. Почему после Rebase может не работать Push
+
+Если ветка была опубликована до Rebase, в Gitea остались старые коммиты, а локально появились новые. Обычный Push может быть отклонён, потому что истории разошлись.
+
+Не нажимайте Force Push самостоятельно. Принудительная отправка способна заменить опубликованную историю и затереть работу другого человека. Остановитесь и обратитесь к ответственному за репозиторий.
+
+После успешного Rebase также помните:
+
+- локальный `main` сам не меняется от Rebase другой ветки;
+- рабочая ветка ещё не принята в `main`;
+- завершением остаётся Pull Request и Merge.
+
+---
+
+## Часть VII. Редкие, но полезные действия
+
+### 41. Временно убрать незавершённые изменения — Stash
+
+**Stash** временно прячет незакоммиченные изменения, чтобы можно было переключиться в другую ветку. Это аварийный карман, а не долговременное хранилище.
+
+Чтобы спрятать изменения, включая новые файлы:
+
+1. нажмите `Ctrl+Shift+P`;
+2. выберите **Git: Stash (Include Untracked)**;
+3. укажите понятное описание, если VS Code его запросит;
+4. убедитесь, что Changes пуст, и переключите ветку.
+
+Чтобы вернуть изменения:
+
+1. вернитесь в исходную ветку;
+2. нажмите `Ctrl+Shift+P`;
+3. выберите **Git: Pop Stash...** или **Git: Pop Latest Stash**;
+4. сразу проверьте файлы и Diff.
+
+После восстановления закончите фрагмент, сделайте Commit и Sync. Не оставляйте единственную копию важной работы в Stash на несколько дней.
+
+### 42. Отметить значимую редакцию — Tag
+
+Коммиты создаются постоянно. **Метка (`Tag`)** закрепляет название за конкретной важной редакцией, например:
+
+```text
+rev-00
+rev-01
+issued-2026-09-02
+```
+
+Метки удобно ставить, когда отчёт направлен на внутреннюю проверку, заказчику, в экспертизу или выпущен как новая редакция. Названия меток должны соответствовать единому правилу проекта.
+
+Создавать метку лучше одному назначенному ответственному:
+
+1. перейти в `main`;
+2. выполнить Sync;
+3. убедиться, что `main` и `origin/main` совпадают;
+4. собрать и проверить отчёт;
+5. открыть Git Graph;
+6. нажать нужный коммит правой кнопкой;
+7. выбрать **Add Tag...**;
+8. указать, например, `rev-00`;
+9. включить отправку на сервер в диалоге или затем выбрать **Push Tag...**.
+
+Локальная метка, которую не отправили, не видна остальным сотрудникам.
+
+<!-- СКРИНШОТ 13: последний коммит main с меткой rev-00 и меню Add Tag / Push Tag. -->
+
+### 43. Fetch, Pull, Push и Sync без лишней теории
+
+| Действие | Что делает | Когда нужно |
+| --- | --- | --- |
+| **Fetch / Получить сведения** | загружает сведения о новых коммитах и ветках, но не меняет рабочие файлы | найти ветку коллеги, обновить Git Graph |
+| **Pull / Вытянуть** | получает серверные коммиты и включает их в текущую локальную ветку | обновить выбранную ветку |
+| **Push / Отправить** | передаёт локальные коммиты текущей ветки в Gitea | опубликовать работу |
+| **Sync / Синхронизировать** | сначала выполняет Pull, затем Push | обычный обмен коммитами в уже опубликованной ветке |
+
+Для ежедневной работы обычно достаточно Sync. Отдельный Fetch полезен, когда нужно увидеть новые серверные ветки без изменения текущих файлов.
+
+### 44. Что означает `origin/...`
+
+При клонировании Git обычно называет связь с Gitea словом `origin`.
+
+```text
+main                 локальная ветка на вашем компьютере
+origin/main          последнее полученное сведение о main в Gitea
+
+work/geology         локальная рабочая ветка
+origin/work/geology  последнее полученное сведение о ней в Gitea
+```
+
+После Fetch указатель `origin/main` может уйти вперёд, а файлы не изменятся. После Pull или Sync локальный `main` догонит его.
+
+Если локальная ветка и соответствующая `origin/...` стоят на одном коммите, их известные состояния совпадают.
+
+---
+
+## Часть VIII. Как должен выглядеть проект
+
+### 45. Во время работы
+
+Несколько рабочих веток — нормальное состояние:
+
+```text
+                         ● ── ●    work/geology
+                        /
+● ── ● ── ● ────────── ●          main
+          \
+           ● ── ● ── ●            work/stability
+```
+
+В `main` находится принятая общая основа. В рабочих ветках находятся незавершённые или ожидающие проверки задачи. Каждый автор регулярно публикует коммиты своей ветки.
+
+### 46. На значимой вехе
+
+После принятия готовых задач они объединены в `main`, отчёт собирается, а нужная редакция отмечена Tag:
+
+```text
+● ── ● ── ● ── ● ── ●    main
+                       ↑
+                     rev-00
+```
+
+Перед выпуском редакции проверьте:
+
+- все принятые изменения находятся в `main`;
+- открытые Pull Request либо приняты, либо осознанно перенесены на следующую редакцию;
+- локальный `main` совпадает с `origin/main`;
+- Source Control пуст;
+- `main.typ` собирается без ошибок;
+- проверены содержание, рисунки, таблицы, ссылки и библиография;
+- Tag установлен на нужный коммит и отправлен в Gitea;
+- итоговый PDF собран именно из этого состояния.
+
+После принятия Pull Request завершённую рабочую ветку можно удалить, если результат уже проверен в `main`. Удаление ветки не удаляет коммиты, вошедшие в `main`. Удалять серверные ветки должен автор или ответственный по принятому правилу команды.
+
+### 47. Что используется с разной частотой
+
+| Частота | Действия |
+| --- | --- |
+| **Постоянно** | проверить текущую ветку, сохранить файл, открыть Source Control, посмотреть Diff, Stage, Commit, Sync |
+| **В начале задачи** | обновить `main`, создать рабочую ветку |
+| **В конце задачи** | собрать отчёт, создать Pull Request, пройти проверку, выполнить Merge, обновить локальный `main` |
+| **Иногда** | Merge свежего `main` в рабочую ветку, разрешить конфликт, Fetch, посмотреть старую версию, Revert |
+| **На значимой редакции** | Tag и контрольная сборка PDF из `main` |
+| **Редко** | Stash, Checkout старого коммита, Rebase |
+
+---
+
+## Часть IX. Если что-то выглядит неправильно
+
+### 48. Сначала проверьте пять вещей
+
+1. **Какая сейчас ветка?** Посмотрите нижний левый угол VS Code.
+2. **Есть ли незакоммиченные файлы?** Откройте Changes и Staged Changes.
+3. **Есть ли стрелки `↑` или `↓`?** Они показывают неотправленные и неполученные коммиты текущей ветки.
+4. **Где `main` и `origin/main`?** Сравните их в Git Graph.
+5. **Где рабочая ветка и её `origin/...`?** Проверьте, опубликована ли последняя работа.
+
+Не исправляйте непонятное состояние случайным Reset, Force Push или удалением файлов.
+
+### 49. Я начал писать и только потом заметил, что нахожусь в `main`
+
+Если изменения ещё не закоммичены:
+
+1. ничего не отбрасывайте;
+2. нажмите название `main` внизу слева;
+3. выберите **Create New Branch**;
+4. назовите ветку по задаче;
+5. убедитесь, что изменения остались в файлах;
+6. продолжите обычный цикл Diff → Stage → Commit → Publish Branch.
+
+При создании ветки незакоммиченные рабочие изменения обычно остаются на месте и оказываются в новой текущей ветке.
+
+Если коммит уже создан в `main`, не выполняйте Push и не используйте Reset без согласования. Обратитесь к ответственному: коммит нужно безопасно перенести в рабочую ветку, не рискуя общей историей.
+
+### 50. После перехода в `main` отчёт выглядит старым
+
+Причина обычно в том, что локальный `main` не получил изменения из Gitea.
+
+1. Убедитесь, что текущая ветка — `main`.
+2. Убедитесь, что Source Control пуст.
+3. Нажмите Sync Changes.
+4. Проверьте в Git Graph, что `main` и `origin/main` совпали.
+
+### 51. После переключения ветки пропал мой текст
+
+Сначала посмотрите название текущей ветки. Если вы перешли из `work/geology` в `main`, Git показывает состояние `main`, где текста ещё нет.
+
+Вернитесь в `work/geology`. Если текст был сохранён коммитом, он появится снова.
+
+### 52. Новая ветка не видна в Gitea
+
+Она существует только локально. После первого коммита нажмите **Publish Branch**. После публикации в Git Graph рядом с локальной веткой должна появиться соответствующая `origin/...`.
+
+### 53. Ветка коллеги не видна
+
+Выполните Fetch и снова откройте Git Graph. Если коллега действительно нажал Publish Branch или Push, появится `origin/work/...`.
+
+### 54. Pull Request объединён, но файлы на моём компьютере не изменились
+
+Merge произошёл в Gitea. Перейдите в локальный `main` и нажмите Sync Changes. Сервер не переключает и не обновляет открытые папки сотрудников автоматически.
+
+### 55. Gitea сообщает о конфликте Pull Request
+
+Обновите рабочую ветку свежим `main`:
+
+```text
+рабочая ветка: Commit и Sync
+→ main: Sync
+→ рабочая ветка
+→ Merge local main into current branch
+→ Merge Editor при необходимости
+→ сборка отчёта
+→ Commit и Sync
+```
+
+Существующий Pull Request обновится автоматически.
+
+### 56. После Sync появился конфликт
+
+Sync сначала выполняет Pull. Значит, в Gitea есть коммиты текущей ветки, которые Git не смог автоматически совместить с локальными.
+
+Откройте Source Control → Merge Changes → Open in Merge Editor. Разрешите конфликт по содержанию, завершите Merge и соберите отчёт. Если вы не ожидали чужих изменений в своей ветке, сначала выясните их автора и назначение.
+
+### 57. Удалённая ветка удалена, но Git Graph продолжает её показывать
+
+Git хранит старое локальное сведение о серверной ветке. В Source Control откройте меню `…` и выберите **Fetch (Prune)**. Это обновит сведения и уберёт устаревшие ссылки `origin/...`, не удаляя обычные рабочие файлы.
+
+### 58. Push отклонён
+
+Не переходите сразу к Force Push. Возможные причины:
+
+- в серверной ветке появились чужие коммиты;
+- ветка была перебазирована;
+- у вас нет права записи;
+- изменился способ авторизации.
+
+Сохраните сообщение ошибки, откройте Git Graph и обратитесь к ответственному за репозиторий. Force Push — не универсальная кнопка исправления.
+
+---
+
+## Часть X. Опасные действия
+
+Git Graph и VS Code показывают больше команд, чем требуется автору отчёта. Без уверенного понимания не используйте:
+
+- **Discard Changes** — удаляет незакоммиченные правки файла;
+- **Reset Current Branch to this Commit**, особенно Hard Reset — перемещает ветку назад и может удалить локальную работу;
+- **Clean Untracked Files** — удаляет новые файлы, которые ещё не добавлены в Git, включая рисунки, CSV и новые главы;
+- **Drop** — удаляет коммит из последовательности и переписывает историю;
+- **Force Push** — заменяет опубликованную историю и может затереть чужие коммиты;
+- **Delete Remote Branch** — удаляет ветку в Gitea для всей команды;
+- **Interactive Rebase** — позволяет переставлять, объединять и удалять коммиты;
+- **Cherry Pick** — копирует отдельный коммит между ветками и может создать дублирование;
+- **Amend Commit** после Push — заменяет уже опубликованный последний коммит;
+- **Force Checkout** — может перезаписать мешающие переключению локальные изменения.
+
+Если ошибка уже опубликована, обычно безопаснее Revert. Если операция ещё не закончена и стала непонятной, используйте Abort Merge или Abort Rebase.
+
+---
+
+## Часть XI. Минимальная памятка
+
+### Перед новой задачей
+
+```text
+Source Control пуст
+→ перейти в main
+→ Sync
+→ Create New Branch
+→ проверить название новой ветки
+```
+
+### Во время работы
+
+```text
+Ctrl+S
+→ Diff
+→ Stage (+)
+→ понятное сообщение
+→ Commit
+→ Publish Branch или Sync
+```
+
+### После окончания
+
+```text
+проверить Diff и собрать отчёт
+→ Sync
+→ Pull Request: рабочая ветка → main
+→ проверка
+→ Merge в Gitea
+→ локальный main
+→ Sync
+```
+
+### При конфликте
+
+```text
+Merge Changes
+→ Open in Merge Editor
+→ проверить обе версии
+→ сформировать Result
+→ Complete Merge
+→ собрать Typst
+→ Continue Merge / Commit
+→ Sync
+```
+
+### Три стоп-сигнала
+
+- Внизу слева `main`, а вы собираетесь писать новую задачу.
+- Source Control показывает непонятные изменения перед переключением или синхронизацией.
+- VS Code предлагает Force Push, Hard Reset, Clean или Force Checkout.
+
+В каждом из этих случаев сначала остановитесь и выясните состояние проекта.
+
+---
+
+## Часть XII. Учебное упражнение
+
+Перед первым настоящим отчётом каждому сотруднику полезно один раз пройти полный цикл в учебном репозитории.
+
+### 1. Создать и опубликовать ветку
+
+1. Клонируйте учебный отчёт.
+2. Перейдите в `main` и нажмите Sync.
+3. Создайте ветку `training/<фамилия>` латиницей.
+4. В учебном `.typ` добавьте одну строку.
+5. Откройте Diff.
+6. Нажмите `+` возле файла.
+7. Создайте коммит `Добавлена тестовая строка`.
+8. Нажмите Publish Branch.
+
+### 2. Увидеть разницу между ветками
+
+1. Перейдите в `main` и убедитесь, что тестовой строки там нет.
+2. Вернитесь в учебную ветку и убедитесь, что строка появилась.
+3. Откройте Git Graph и найдите место, где ветка отделилась от `main`.
+
+### 3. Принять работу
+
+1. В Gitea создайте Pull Request `training/<фамилия> → main`.
+2. Попросите коллегу посмотреть изменения.
+3. Выполните Merge учебного Pull Request.
+4. В VS Code перейдите в `main` и нажмите Sync.
+5. Убедитесь, что тестовая строка теперь находится в `main`.
+
+### 4. Один раз специально создать конфликт
+
+Учебный конфликт лучше увидеть до настоящего проекта. Преподаватель и сотрудник меняют одну и ту же строку в разных ветках. Затем сотрудник обновляет рабочую ветку через Merge `main → рабочая ветка` и в Merge Editor:
+
+1. сравнивает Incoming и Current;
+2. вручную формирует правильный Result;
+3. завершает Merge;
+4. собирает Typst;
+5. создаёт коммит и выполняет Sync.
+
+После этих упражнений сотрудник уже видел весь основной цикл: отдельная работа, история, публикация, проверка, объединение и получение общего результата.
+
+---
+
+## Краткий словарь
+
+| Термин | Простое значение |
+| --- | --- |
+| **Репозиторий** | папка проекта вместе с историей изменений |
+| **Локальный** | находящийся на вашем компьютере |
+| **Удалённый / remote** | находящийся в Gitea |
+| **Commit / коммит** | именованная контрольная точка работы |
+| **Branch / ветка** | отдельная линия работы над задачей |
+| **main** | основная принятая версия отчёта |
+| **Stage** | выбрать изменения для следующего коммита |
+| **Diff** | сравнить прежнее и новое содержимое |
+| **Push** | отправить локальные коммиты в Gitea |
+| **Pull** | получить серверные коммиты в текущую ветку |
+| **Fetch** | обновить сведения о сервере, не меняя рабочие файлы |
+| **Sync** | последовательно выполнить Pull и Push |
+| **Checkout** | переключиться на ветку или историческую точку |
+| **Pull Request** | предложить проверить и принять рабочую ветку в `main` |
+| **Merge** | объединить изменения двух веток |
+| **Conflict** | место, где итог должен определить человек |
+| **Rebase** | перенести коммиты ветки на другое основание с переписыванием их истории |
+| **Revert** | создать новый коммит, отменяющий прежний |
+| **Stash** | временно спрятать незакоммиченные изменения |
+| **Tag** | постоянная метка значимой редакции |
+| **origin/main** | последнее полученное Git сведение о ветке `main` в Gitea |
+
+Главная логика Git остаётся простой: каждый готовит одну понятную задачу в своей ветке, сохраняет работу коммитами, отправляет её в Gitea и после проверки включает в общий `main` через Pull Request.