Сдача работ через GitLab: регламент и справочник по git

Документ описывает процесс сдачи лабораторных, курсовых и домашних работ по дисциплинам кафедры ИИЦТ и даёт справочник по git и GitLab для тех, кто раньше с ними не работал. Регламент единый для всех дисциплин кафедры — и для магистратуры, и для бакалавриата. Прочитайте один раз внимательно перед первой сдачей — дальше документ пригодится как справочник.

Конкретные детали курса (название, слаг проекта, список работ, логин преподавателя) уточняет преподаватель на первом занятии. В этом регламенте такие места обозначены заглушками в угловых скобках: <course-slug>, <логин-преподавателя> и т. п.

1. Ключевые понятия

Перед тем как что-то делать, нужно понимать что такое git, что такое GitLab, и чем они отличаются. Путаница между этими двумя понятиями — главный источник недоразумений у новичков.

1.1. Что такое git

Git — программа, которая ведёт историю изменений файлов в папке с проектом. Её задачи простыми словами:

• запоминать, кто и что менял в файлах проекта;
• позволять откатиться на любое прошлое состояние, если в коде что-то сломалось;
• позволять нескольким людям работать над одним проектом, не переписывая друг другу правки.

Git — это консольная программа, которая живёт на вашем компьютере. Она работает с папкой, внутри которой лежит ваш проект. Никакого «сервера» для работы git как таковой не требуется. Весь механизм запоминания истории работает локально, в скрытом каталоге .git/ внутри папки проекта.

Аналогия из жизни: git — это как Word с постоянно включённой функцией «История изменений», только на стероидах. Она запоминает не одну версию документа, а всю цепочку правок — от создания файла до сегодняшнего дня.

1.2. Что такое GitLab

GitLab — это веб-сайт (и сервер за ним), куда можно положить копию своего проекта, чтобы она хранилась в интернете, а не только у вас на ноутбуке. GitLab:

• хранит копии репозиториев — как «облако» для кода;
• показывает их в веб-интерфейсе: можно читать файлы, смотреть историю, искать;
• умеет показывать изменения, которые один разработчик предлагает внести, чтобы другой их прочитал и утвердил (это называется Merge Request);
• умеет запускать автоматические проверки (тесты, линтеры) при каждом изменении (CI/CD);
• управляет доступами: кто имеет право читать и менять проект.

Аналоги GitLab — GitHub (самый известный), Bitbucket. На нашей кафедре используется собственный экземпляр GitLab: git.aidt.online.

Важное различие: git — это программа, которая запускается у вас локально. GitLab — это веб-сервис, через который копии ваших проектов становятся доступны преподавателю и одногруппникам. Можно использовать git без GitLab (например, для личных заметок), но не наоборот.

1.3. Репозиторий

Репозиторий (англ. repository, сокращённо — репо) — папка с проектом, в которой git ведёт историю. Снаружи — обычная папка с файлами вашего кода. Внутри — скрытый каталог .git/, где git хранит всю историю изменений. Туда лучше руками не лазать.

Два способа создать репозиторий:

• С нуля, на пустом месте. Команда git init превращает обычную папку в репозиторий. Нужна, если вы начинаете проект с чистого листа.
• Клонированием с сервера. Команда git clone <URL> скачивает копию существующего репозитория с GitLab на ваш компьютер. Нужна, когда проект уже создан на сервере (в наших курсах — это основной способ).

1.4. Рабочая папка, индекс, история

Когда вы меняете файлы в репозитории, правки проходят через три условные зоны:

1. Рабочая папка  →  2. Индекс (staging)  →  3. История (commits)
      редактирование       git add                 git commit
      файлов               добавить в              зафиксировать
                           «пачку»                 «пачку»

1. Рабочая папка (англ. working directory) — это привычные файлы, которые вы открываете и правите в редакторе.
2. Индекс (англ. staging area, index) — промежуточный буфер, куда вы явно кладёте готовые изменения, которые хотите закрепить. Это как «корзина перед кассой»: вы собрали в неё товары, но чек ещё не пробили. Индекс нужен, чтобы разбить много разных правок на несколько осмысленных коммитов, а не заталкивать их в один.
3. История — последовательность коммитов. Каждый коммит — это снимок состояния всех файлов проекта на момент фиксации, с сообщением и подписью автора.

Команда git add <файл> переносит правку из рабочей папки в индекс. Команда git commit берёт всё, что лежит в индексе, и делает новый коммит в историю. После этого индекс пустеет — пока вы не положите в него следующую порцию правок.

1.5. Коммит

Коммит (англ. commit) — единица истории. Один коммит содержит:

• снапшот состояния всех файлов проекта на момент коммита;
• сообщение — текстовое описание, что и зачем поменялось;
• автора и время — ФИО, email, дата;
• ссылку на предыдущий коммит (так коммиты связаны в цепочку).

У каждого коммита есть уникальный хэш — строка вида a3f7b1c9d2e5f80a… длиной 40 символов. Обычно достаточно первых 7–8 символов, чтобы однозначно на него сослаться. Хэш генерируется автоматически; его видно в команде git log.

Правила для сообщений коммитов:

1. Повелительное наклонение, без точки в конце: «Добавить разметку дашборда», не «Добавил», не «Добавление», не «Добавлен каркас».
2. Одно логическое изменение — один коммит. Если вы одновременно добавили разметку, исправили опечатку и переименовали файл — это три разных коммита, а не один.
3. Запрещённые формулировки, которые будут снижать баллы: wip, fix, ., update, правки, ещё, lab1, коммит, пустая строка. По сообщению коммита должно быть понятно, что именно было сделано, без необходимости открывать diff.

Почему именно повелительное наклонение — это не прихоть, а общепринятая в индустрии конвенция (она же используется и самим git — автогенерируемые сообщения вроде Merge branch 'x' и Revert "..." написаны в повелительном). Работает простое правило: коммит отвечает на вопрос «что произойдёт, если я применю этот коммит?», и ответ естественно звучит как команда — «Добавить X», «Исправить Y», «Удалить Z». Повелительная форма короче, единообразна по виду (все коммиты выглядят одинаково, независимо от рода автора и времени) и читается как список действий, а не как отчёт «кто что сделал». Приходя в любой промышленный проект, вы встретите тот же стиль — привыкать к нему лучше сразу.

Пример хорошей истории из шести коммитов:

Добавить каркас HTML-документа и Open Graph-метатеги
Разметить шапку и главную навигацию
Разметить секцию «Расписание на сегодня»
Разметить карточки дисциплин
Исправить вложенность <address> в футере
Добавить отчёт lab-01/report.md

По этому списку уже видно структуру работы, не глядя в diff.

1.6. Ветка

Ветка (англ. branch) — именованный указатель на один из коммитов истории. Ветки нужны, чтобы вести несколько параллельных линий разработки в одном репозитории, не мешая друг другу.

На практике: у вас есть основная ветка с «официальной» версией проекта (main). Когда вы начинаете новую задачу, вы создаёте от неё отдельную ветку — отводите в сторону свою временную копию истории. В ней вы коммитите свои правки. Когда работа закончена, эту ветку сливают обратно в основную.

В курсе используются только две роли веток:

• main — главная ветка проекта. В неё попадают только готовые, проверенные преподавателем работы через Merge Request. Прямой push в main запрещён настройкой protected branch.
• lab-{xx}/v1 — рабочая ветка для конкретной лабораторной или домашней работы. Создаётся от актуального main, в ней вы коммитите свои правки, потом она сливается в main через Merge Request. Номер xx — номер работы: lab-01/v1, lab-02/v1, и так далее. Суффикс v1 оставлен на случай, если работу придётся переделывать: тогда вторая попытка будет в lab-01/v2. Для домашних работ по аналогии — homework-01/v1, для курсовой — coursework/v1.

1.7. Удалённый репозиторий

Удалённый репозиторий (англ. remote) — копия репозитория на сервере, куда вы отправляете свои коммиты из локальной копии. В нашем случае это проект на git.aidt.online.

Когда вы клонируете проект с сервера командой git clone, git автоматически запоминает адрес удалённого репозитория под именем origin. Дальше две главные команды:

• git push — отправить ваши локальные коммиты на сервер;
• git pull — забрать с сервера коммиты, которых у вас локально нет.

«Локально поработали → отправили на сервер через push» — это основной цикл работы с GitLab.

1.8. Merge Request

Merge Request (MR) — способ «предложить» слияние своей ветки в основную и получить review от преподавателя. Когда вы закончили работу над лабораторной в ветке lab-01/v1 и запушили её, вы открываете в GitLab Merge Request «из lab-01/v1 в main». Преподаватель видит все ваши изменения, оставляет замечания построчно, вы правите и отвечаете. Когда всё устраивает — преподаватель ставит Approve, вы нажимаете кнопку Merge, ветка сливается с main.

Merge Request = способ сдать работу. Без него сдача не засчитывается технически.

На GitHub этот же процесс называется Pull Request; смысл идентичный.

2. Установка и настройка git

2.1. Установка

Git нужно установить один раз на свой компьютер.

• Windows: скачать установщик Git for Windows. В установщике жмите «Next» по всем пунктам (дефолтные настройки безопасны). В комплекте идут: сам git, консоль Git Bash (удобная для Windows), минимальный редактор.
• macOS: git обычно уже установлен. Проверьте командой git --version в Терминале. Если нет — поставьте Xcode Command Line Tools: xcode-select --install. Альтернативно: brew install git, если установлен Homebrew.
• Linux (Ubuntu/Debian): sudo apt install git в терминале.

Проверка: в терминале (Git Bash на Windows, Terminal.app на macOS, любой — на Linux) выполните:

git --version

Должно вывести что-то вроде git version 2.43.0. Версия 2.40+ — норма; более старая может тоже подойти, но лучше обновить.

2.2. Базовая настройка git

Выполняется один раз после установки. Эти команды нужно запустить в терминале один за другим:

git config --global user.name "Иван Иванов"
git config --global user.email "i_ivanov@aidt.online"
git config --global init.defaultBranch main
git config --global pull.rebase false
git config --global core.autocrlf input

Разбор каждой команды:

• user.name и user.email — подписываются в каждом вашем коммите. Укажите своё реальное ФИО (как в зачётной книжке) и ту же почту, которая привязана к вашей учётной записи на git.aidt.online. Если email будет не тот, GitLab не свяжет коммиты с вашим профилем, и в web-интерфейсе коммиты будут без аватара.
• init.defaultBranch main — новые репозитории сразу получают ветку main (а не устаревшее имя master).
• pull.rebase false — при git pull использовать merge, а не rebase. Для новичков это безопаснее.
• core.autocrlf input (важно для Windows) — не портит переводы строк в текстовых файлах при push/pull. Без этой настройки Windows-пользователи часто ломают файлы.

Проверка настроек:

git config --global --list

Увидите список того, что настроили. Если где-то опечатка — повторите соответствующую команду с правильным значением, она перезапишет прежнее.

3. Доступ к git.aidt.online по HTTPS

На git.aidt.online настроен только HTTPS-доступ. SSH не поддерживается.

При каждом push/pull git будет спрашивать ваши учётные данные: логин с git.aidt.online и Personal Access Token (PAT) вместо пароля. Использовать обычный пароль от аккаунта нельзя — GitLab по соображениям безопасности требует токен.

3.1. Создание Personal Access Token

Токен создаётся один раз и дальше живёт на вашей машине. Шаги:

1. Войти на git.aidt.online своим корпоративным аккаунтом.
2. Правый верхний угол → щёлкнуть по аватару → Preferences (в левом меню) → Access Tokens.
3. Add new token. Параметры:
   • Token name — любое понятное имя, например cli-ноутбук;
   • Expiration date — дата истечения. Ставьте дату конца учебного года (или максимум на 1 год — GitLab не даст больше). Когда токен истечёт, создадите новый.
   • Select scopes — отметить галочками:
     • ✅ read_repository — читать код из репозиториев;
     • ✅ write_repository — пушить изменения.
     • Остальные scopes не нужны.
4. Нажать Create personal access token.
5. Скопировать показанный токен — длинная строка вида glpat-XXXXXXXXXXXXXXXXXXXX. GitLab покажет его только один раз; если потеряете — придётся создавать новый.
6. Сохранить в надёжном месте: менеджер паролей (Bitwarden, 1Password, KeePass), или временно — в заметки. Не коммитьте токен в репозиторий, это утечка учётки.

Токен используется как замена пароля при любых операциях git с git.aidt.online.

3.2. Настройка credential helper — чтобы не вводить токен каждый раз

Чтобы не вбивать логин и токен при каждом push/pull, включите кеширование учёток:

• Windows: ничего делать не нужно — Git for Windows по умолчанию использует Git Credential Manager, который хранит токен в Credential Manager Windows. При первом push откроется окно «Sign in to your account» — введите логин и токен, дальше git их запомнит.
• macOS: включить встроенный keychain-хелпер:

  git config --global credential.helper osxkeychain
  

  При первом push Terminal попросит логин и токен, дальше они лягут в Keychain.
• Linux: включить кеширование в памяти на 12 часов (достаточно на учебный день):

  git config --global credential.helper 'cache --timeout=43200'
  

  Для постоянного хранения поставьте libsecret credential helper или используйте store (менее безопасно — токен в открытом виде в файле, годится только на личной машине).

После настройки — первый push спросит учётку, все следующие пройдут без вопросов.

3.3. Что вводить в поле «логин» и «пароль»

• Username / Логин: ваш логин на git.aidt.online (тот, что вы используете при входе на сайт — например, i_ivanov).
• Password / Пароль: Personal Access Token (glpat-…), не пароль от аккаунта.

Если git пишет «authentication failed» — 99 % случаев это:

1. Введён пароль вместо токена.
2. Токен истёк.
3. У токена не отмечен scope write_repository.

4. Создание проекта в GitLab

Выполняется один раз на весь курс. Один личный проект используется для всех лабораторных и домашних работ по одной дисциплине — ветки разделяют задания внутри.

4.1. Имя проекта

Имя проекта задаёт преподаватель на первом занятии — в виде короткого слага латиницей, одинакового для всех студентов, сдающих этот курс. Это важно: одинаковое имя у всех облегчает преподавателю навигацию по десяткам студенческих проектов, а студенту — поиск своего проекта по прямой ссылке.

Формат: <course-slug>, например web-frontend, databases, nodejs. Полный путь к вашему проекту получится такой: git.aidt.online/<ваш-логин>/<course-slug>.

Если преподаватель не назвал слаг — уточните до первой сдачи; не придумывайте название самостоятельно.

4.2. Создание проекта

1. Войти на git.aidt.online.
2. Верхнее меню → + (New) → New project → Create blank project.
3. Заполнить поля:
   • Project name — слаг курса, который дал преподаватель (<course-slug>).
   • Project URL — выбрать ваш личный нэймспейс (git.aidt.online/<ваш-логин>). НЕ группу курса, НЕ командную подгруппу. Проект должен лежать в вашем собственном аккаунте.
   • Project slug — автоматически подставится из Project name, трогать не нужно.
   • Visibility Level — Private. Никто, кроме вас и приглашённого преподавателя, не увидит содержимое.
   • Initialize repository with a README — ✅ поставить галочку. Это создаст ветку main с первым пустым коммитом; без неё клонирование будет выдавать ошибку «empty repository».
4. Нажать Create project.
5. Пригласить преподавателя. Слева в меню проекта → Manage → Members → Invite members:
   • Select members to invite — начните вводить ФИО или логин преподавателя курса, выберите из выпадающего списка;
   • Select a role — Developer;
   • Access expiration date — можно оставить пустым или поставить дату конца семестра;
   • Invite.
   
   Без этого шага сдача технически невозможна: преподаватель не увидит ни проект, ни Merge Request. Логин преподавателя узнайте на первом занятии.
6. Защитить ветку main. Слева: Settings → Repository → Protected branches → Add protected branch:
   • Branch — main;
   • Allowed to merge — Developers + Maintainers;
   • Allowed to push and merge — Maintainers (то есть только вы; преподаватель не будет сам пушить в вашу ветку).
   • Protect.

Теперь настройки готовы. Любое изменение в main возможно только через Merge Request. Это спасает от случайного прямого push, который мог бы испортить историю.

5. Структура проекта и отчёты

Чтобы преподавателю было одинаково удобно искать работы у всех студентов, структура папок в репозитории — единая.

5.1. Структура папок

<course-slug>/
├── README.md                # короткое описание репозитория: ФИО, группа, курс
├── .gitignore
├── lab-01/                  # папка с лабораторной 1
│   ├── <файлы решения>      # index.html, styles/, src/, ... — как требует задание
│   └── report.md            # отчёт по лабораторной (см. 5.2)
├── lab-02/
│   └── ...
├── homework-01/             # домашние задания (если предусмотрены курсом)
│   └── ...
└── coursework/              # курсовая работа (если предусмотрена курсом)
    └── ...

Правила:

• Одна работа — одна папка верхнего уровня. Номер двузначный с ведущим нулём (lab-01, а не lab-1), чтобы сортировка в файловом менеджере и на GitLab шла по-человечески.
• Отчёт лежит внутри папки работы под именем report.md, а не в отдельном дереве reports/. Так задание и отчёт про него всегда рядом.
• Имена папок и файлов — латиницей, в нижнем регистре, через дефис. Без пробелов, без кириллицы, без заглавных. Примеры: lab-03-semantic-markup/ допустимо, если преподаватель просит уточнять тематику в имени; иначе хватит lab-03/.
• Не плодите лишние уровни вложенности. Исходники задания — прямо в lab-XX/, а не в lab-XX/src/, если в задании нет сборки. Решение «папка внутри папки ради папки» только мешает ревью.

5.2. Отчёт по работе: формат и структура

Отчёты сдаются в формате Markdown (.md), не Word, не PDF. Причины:

• Markdown отображается GitLab прямо в веб-интерфейсе — преподаватель читает отчёт там же, где смотрит код, без скачивания файлов.
• Markdown — это обычный текст, он корректно мёрджится и diff-ится в git; Word и PDF — бинарники, в них git видит только «файл изменился целиком».
• Писать Markdown учишься за 15 минут, этот навык пригодится везде: GitLab, GitHub, Notion, большинство вики, документация опенсорсных проектов.

Обязательная структура report.md:

# Лабораторная <NN>. <Название работы>

**Студент:** Иванов Иван Иванович, группа <ХХХ-123>
**Дата сдачи:** 2026-04-15

## Цель работы

Одно-два предложения: что именно осваивается на этой работе.

## Задание

Краткий пересказ задания своими словами — чтобы отчёт был понятен без открытия методички.

## Ход выполнения

Описание того, как вы решали задание, в хронологическом порядке. По шагам: что сделали, чем пользовались, какие трудности встретили и как решали. Сюда же — фрагменты кода (в ``` блоках ```), ссылки на файлы решения, скриншоты (кладите в `lab-XX/screenshots/` и вставляйте как `![подпись](screenshots/имя.png)`).

## Результаты

Что получилось в итоге. Ссылки на ключевые файлы решения. Если задание требовало запустить что-то и увидеть результат — скриншот итогового состояния.

## Ответы на контрольные вопросы

Если в задании есть контрольные вопросы — ответьте на них по порядку, списком. Без этого раздела работа не защищается.

## Выводы

Два-три предложения: чему научились, какой инструмент освоили, где это пригодится.

## Источники

Список материалов, которыми пользовались помимо методички: статьи, документация, видео. С прямыми ссылками.

Разделы, которые не применимы к конкретной работе (например, в задании нет контрольных вопросов), можно опускать — но не переименовывать и не путать порядок.

Если вы раньше не писали в Markdown — освойте за один вечер. Минимум, которым нужно владеть: заголовки (#, ##), списки, ссылки, изображения, блоки кода, таблицы, выделение жирным/курсивом. Справочники и спецификации — в разделе 12; начать проще всего с Markdown Guide и «Доки», остальное пригодится, когда столкнётесь с нюансами.

Проверяйте отчёт на GitLab, а не только в редакторе: именно так его увидит преподаватель. Для локального предпросмотра — встроенный Markdown Preview в VS Code (Ctrl+Shift+V).

6. Клонирование проекта и первый коммит

6.1. Клонирование

Получить копию только что созданного проекта на свой компьютер:

1. На странице проекта в GitLab в правом верхнем углу нажать Code → Clone with HTTPS → кнопка копирования. Получите URL вида https://git.aidt.online/<ваш-логин>/<course-slug>.git.
2. В терминале перейти в папку, где вы храните учебные проекты (не прямо в Documents, а в отдельную папку, например ~/projects/):

   cd ~/projects
   git clone https://git.aidt.online/<ваш-логин>/<course-slug>.git
   cd <course-slug>
   

3. Git попросит логин и токен (в первый раз); введите их. После — команда завершится и в папке <course-slug>/ появятся файлы проекта (пока только README.md и скрытый .git/).

Если клонирование падает с ошибкой — см. раздел 10.

6.2. Файл .gitignore

Создайте в корне проекта файл .gitignore — список путей, которые git должен игнорировать. Без него в репозиторий попадут системные и редакторские файлы, которые там не нужны.

Универсальное содержимое .gitignore, подходящее для большинства курсов:

# Операционная система
.DS_Store
Thumbs.db

# Редакторы и IDE
.vscode/
.idea/
*.swp
*~

# Зависимости и сборки (для курсов с Node.js/фронтендом)
node_modules/
dist/
build/
.cache/

# Переменные окружения — часто содержат секреты
.env
.env.local

Если в вашем курсе используются другие языки и инструменты — добавьте соответствующие строки (например, __pycache__/, *.pyc для Python; target/ для Rust/Maven; bin/, obj/ для .NET). Готовые шаблоны для разных экосистем — на github.com/github/gitignore.

Что делать, если эти файлы уже закоммичены: добавьте их в .gitignore, потом удалите из индекса командой git rm --cached <путь>, закоммитьте удаление.

6.3. Первая попытка коммита

Создайте .gitignore содержимым из предыдущего пункта и сделайте первый коммит:

git status                              # посмотреть, что git видит — увидите .gitignore в untracked
git add .gitignore                      # добавить в индекс
git status                              # теперь файл в staging
git commit -m "Добавить .gitignore"     # зафиксировать в историю
git push                                # отправить на сервер

После git push обновите страницу проекта в GitLab — увидите новый коммит в истории.

7. Работа над заданием

Дальнейший цикл повторяется для каждой лабораторной / домашней работы.

7.1. Начать новую ветку

Перед началом любой работы — обновить локальный main и создать от него рабочую ветку:

git switch main                 # переключиться на main
git pull                        # подтянуть последние изменения с сервера
git switch -c lab-01/v1         # создать новую ветку и сразу на неё перейти

Разбор:

• git switch main — переключение между ветками.
• git pull — скачивает свежее состояние с сервера. Актуально, если вы принимали чужие правки или сливали прошлые работы с другого устройства.
• git switch -c <имя> — флаг -c означает create: создать новую ветку от текущего коммита и сразу переключиться на неё.

7.2. Цикл «правка — коммит»

Пока вы пишете код, повторяется этот цикл:

# 1. Редактируете файлы в редакторе (VS Code, WebStorm, любой)

# 2. Посмотреть, что изменилось
git status                      # списком
git diff                        # построчно (q — выход)

# 3. Добавить конкретные изменения в индекс
git add lab-01/index.html       # только этот файл
git add .                       # ВСЁ изменённое сразу (осторожно — может подхватить лишнее)

# 4. Зафиксировать
git commit -m "Добавить разметку карточек дисциплин"

# 5. Повторять шаги 1–4 после каждой смысловой порции работы

Почему часто коммитить — хорошо:

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

Как часто коммитить — по каждому смысловому шагу. Разметили шапку — коммит. Разметили секцию дисциплин — коммит. Поправили вложенность тегов — отдельный коммит.

7.3. Отправка на сервер

Периодически (минимум — в конце каждого учебного дня) отправляйте свои коммиты на сервер:

git push -u origin lab-01/v1    # первый push новой ветки, флаг -u привязывает её к серверу
git push                         # все следующие — просто git push

После первого git push -u git запоминает, что локальная ветка lab-01/v1 связана с одноимённой веткой на сервере. Это называется upstream. Следующие push и pull этой ветки работают без уточнений.

Почему пушить важно не только перед сдачей:

• Если ноутбук сломается — работа не пропадёт.
• Преподаватель может посмотреть промежуточное состояние и подсказать раньше, чем вы вообще откроете MR.
• Вы сможете продолжить работать с другого устройства, просто клонировав проект.

7.4. Полезные команды

• git log --oneline — история коммитов в виде одной строки на коммит. q — выйти из пейджера.
• git log --oneline --graph --all — то же, но с визуальным графом веток. Полезно, когда не понимаете, где вы в истории.
• git diff — что изменилось в рабочей папке против последнего коммита.
• git diff --staged — что лежит в индексе и попадёт в следующий коммит.
• git restore <файл> — необратимо откатить изменения в файле до последнего коммита. Осторожно, несохранённая работа пропадёт.
• git restore --staged <файл> — убрать файл из индекса (не трогает содержимое, просто «разстейджит»).
• git commit --amend — изменить последний коммит (сообщение или добавить забытый файл). Только если коммит ещё не запушен на сервер. После push — нельзя.
• git switch <ветка> — переключиться на существующую ветку.
• git branch — список локальных веток. Текущая помечена звёздочкой.

8. Merge Request и защита

Когда работа в ветке закончена, все коммиты запушены, отчёт лежит в lab-XX/report.md — пора открывать Merge Request.

8.1. Открыть MR

1. Убедитесь, что ветка актуальна на сервере: git push.
2. Открыть проект в GitLab. Сверху часто всплывает баннер «You pushed to lab-01/v1 just now. Create merge request». Кликнуть — сразу попадёте в форму создания MR.
   Альтернативно: слева Merge Requests → New merge request.
3. Параметры MR:
   • Source branch — lab-01/v1.
   • Target branch — main.
   • Title — Лабораторная 01. <Короткое название задания> (формат: номер + короткое название задания).
   • Description — одно-два предложения о составе изменений, ссылка на lab-01/report.md, если требуется приложить скриншот (например, валидатора) — перетащите файл прямо в поле описания, GitLab загрузит и вставит ссылку.
   • Reviewers — преподаватель курса (начните вводить, выберите из списка).
   • Delete source branch when merge request is accepted — ✅ оставить галочку. После merge ветка lab-01/v1 удалится с сервера — это нормально, её история уже в main.
4. Create merge request.

8.2. Защита в обсуждениях

Дальше начинается code review:

• Преподаватель открывает вкладку Changes в MR, читает diff.
• Оставляет inline-замечания — комментарии, привязанные к конкретным строкам кода. Каждое замечание становится отдельной дискуссией (thread).
• Вы видите замечания во вкладке Overview или Changes. На каждое нужно ответить:
  • Коммитом, исправляющим проблему. Закоммитили → запушили → коммит автоматически появляется в MR, дискуссия обновляется.
  • Текстом, если вы не согласны или хотите обсудить.
• Когда замечание закрыто, преподаватель помечает дискуссию Resolve thread. Когда все дискуссии Resolved — преподаватель ставит Approve.

После Approve кнопка Merge становится активной. Мёрджит MR сам студент — это часть сдачи, осознанное подтверждение, что работа завершена.

После Merge:

• ветка lab-01/v1 удаляется автоматически;
• ваши коммиты появляются в main (в веб-интерфейсе и после git pull у вас локально);
• вы готовы начинать lab-02/v1.

8.3. Очная защита

Часть замечаний и контрольные вопросы разбираются очно на практическом занятии. К защите студент приходит:

• с открытой страницей в браузере;
• с открытым проектом в GitLab;
• готовым отвечать на контрольные вопросы по материалам соответствующей темы;
• готовым показать своё решение, обосновать выбор подхода, продемонстрировать работу в браузере/инструменте, если применимо.

После очной защиты преподаватель ставит Approve в MR, студент мёрджит.

9. Доработка после ревью

Если MR вернули на доработку — спокойно. Это стандартная часть процесса, не двойка.

9.1. Обычная доработка

Правки замечаний делаются в той же ветке lab-01/v1:

git switch lab-01/v1            # вернуться в свою ветку (если вдруг ушли)
# правите файлы по замечаниям
git add <файлы>
git commit -m "Исправить уровни заголовков по замечаниям ревью"
git push

Merge Request автоматически подхватит новые коммиты. В дискуссиях GitLab покажет, что добавились коммиты X, Y, Z с прошлого push. Ответьте на замечания в тех тредах, которые правили, и попросите преподавателя посмотреть ещё раз.

9.2. Глубокая переделка с нуля

Если работа не принимается в принципе и нужно переделывать с чистого листа:

1. Закрыть старый MR без мёрджа кнопкой Close merge request. В комментарии указать: «Отзываю, переделываю, открою v2».
2. Завести новую ветку от актуального main:

   git switch main
   git pull
   git switch -c lab-01/v2
   

3. Работать как обычно, в итоге открыть новый MR в main.

10. Частые ошибки и как их избежать

• «Push отклонён: protected branch main». Вы пытаетесь запушить прямо в main. Это запрещено настройкой. Правильно: создайте ветку lab-XX/v1, коммитьте туда, пушьте, открывайте MR. Команда «вернуть всё в свою ветку»:

  git switch -c lab-XX/v1        # создать ветку из текущего состояния
  git push -u origin lab-XX/v1   # запушить уже сюда
  git switch main
  git reset --hard origin/main   # ОСТОРОЖНО: откатить main к серверному состоянию
  

• «Authentication failed». Неправильный токен (см. раздел 3). Вариант 99%: вы ввели пароль от аккаунта вместо Personal Access Token. Перечитайте 3.3 и попробуйте снова. Если credential helper уже сохранил неправильные данные — их нужно очистить:
  • Windows: Control Panel → Credential Manager → найти запись git:https://git.aidt.online → удалить.
  • macOS: Keychain Access → найти git.aidt.online → удалить.
  • Linux с credential.helper=store: удалить запись из ~/.git-credentials.
• «Divergent branches» при git pull. Возникает, если на сервере ветка ушла вперёд одним способом, а у вас локально — другим. Обычно значит, что кто-то (или вы сами с другого устройства) запушил коммиты, и у вас своих локальных есть параллельно. Решение:

  git pull --no-rebase         # сделает merge, git попросит ввести сообщение merge-коммита
  # :wq в редакторе vim, или Ctrl+X → Y → Enter в nano — подтвердить и выйти
  

• Попавшие в репозиторий .DS_Store, node_modules, .vscode/. Добавьте их в .gitignore, потом удалите из репозитория командой:

  git rm -r --cached .DS_Store node_modules .vscode
  git commit -m "Удалить системные и редакторские файлы из репозитория"
  git push
  

  
  Из истории прошлых коммитов они не исчезнут, но новые коммиты попадать не будут.
• Коммит с чужим email. Если вы клонировали чужой репо или работаете с нескольких машин, возможно git config user.email настроен глобально на другой email. Проверьте в папке проекта:

  git config user.email
  

  
  Если не ваш — поправьте глобально (раздел 2.2) или локально для этого проекта:

  git config user.email "i_ivanov@aidt.online"
  

  
  Прошлые коммиты останутся с чужим email (исправлять их — больная тема, не трогайте), но новые будут корректными.
• Забыли git add перед коммитом, закоммитили пусто / не то. Если ещё не запушили — поправьте последний коммит:

  git add <нужный файл>
  git commit --amend --no-edit
  

  
  Если уже запушили — не используйте --amend, сделайте новый коммит с нужными файлами.
• Большие коммиты «всё сразу». Не ругаемся: отмотать уже не получится, но следующие коммиты делайте осмысленнее. История чинится постепенно.
• Работа пропала при git restore или переключении ветки. Если закоммичены — найдутся через git reflog (показывает вообще все движения указателя HEAD), но это не для новичков. Золотое правило: коммитьте часто и пушьте в конце дня.
• «Nothing to commit, working tree clean», хотя файлы менялись. Убедитесь, что вы в правильной ветке (git branch) и в правильной папке (pwd). Часто — файлы изменены в папке, которая в .gitignore.

11. Краткий глоссарий

12. Что читать дальше

Документ даёт необходимый минимум. Если хочется глубже:

По git и GitLab

• Pro Git book — русский перевод. Каноническая бесплатная книга по git. Главы 1–3 покрывают всё, что нужно в первый год работы.
• Learn Git Branching (learngitbranching.js.org). Интерактивный тренажёр: даёт задачи с визуализацией графа коммитов, решаете командами git в браузере. Лучший способ «увидеть» ветки и merge.
• Git cheat sheet от GitHub Education. Одностраничная шпаргалка с командами; распечатайте и положите рядом с ноутбуком.
• Oh Shit, Git!? (ohshitgit.com/ru). Короткие рецепты «я всё сломал, как откатить». На удивление полезно в первый месяц.
• Дока: git. Русскоязычный справочник от сообщества, хорошо объясняет основы.
• Руководство по Merge Requests (GitLab docs). Официальная документация, если хочется знать все возможности MR-интерфейса.

По Markdown (для оформления отчётов, см. 5.2)

• Markdown Guide (русский перевод) — основы и расширенный синтаксис; начать лучше с «Basic Syntax».
• Дока: Markdown — краткий русскоязычный справочник от сообщества, с интерактивными примерами.
• CommonMark Spec — эталонная спецификация языка; полезна, когда рендер повёл себя неожиданно и хочется понять «а как правильно».
• GitHub Flavored Markdown Spec — расширения базового Markdown (таблицы, чекбоксы, зачёркивание, подсветка кода). GitLab поддерживает GFM, то есть всё оттуда у вас работает.
• GitLab Flavored Markdown — что GitLab умеет поверх GFM (ссылки на issues, MR, упоминания пользователей, mermaid-диаграммы).

Всё, что не покрыто этим документом — ищется в первых трёх ссылках раздела про git.