639 lines
39 KiB
Markdown
639 lines
39 KiB
Markdown
# 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.
|