Вы научитесь возвращать потерянную работу из reflog, приводить историю в порядок через rebase и чинить репозиторий после аварий: удалённая ветка, ключ в коммите, чужой force-push. Знакомая картина: reset --hard выполнен, а коммитов в git log нет. Ставить ничего не нужно: лабораторные идут в браузере на настоящем Git в живом терминале.
После reset --hard HEAD~3 git log показывает один коммит, git log --all тоже. Работа выглядит стёртой, но коммиты лежат в базе объектов, и до них ведёт журнал HEAD.
Вы читаете reflog так, как его печатает Git: номер записи, хеш, действие. Находите последний коммит перед сбросом и возвращаете ветку одной командой. Потом разбираете, как то же самое делается после удалённой ветки и после rebase.
Тест зелёный на метке v1.0 и красный на HEAD: заказ ровно на 100 единиц считается без сниженной цены. Названия коммитов ничего не подсказывают, а читать сорок диффов долго.
Вы ведёте поиск вручную, потом отдаёте его скрипту через git bisect run и узнаёте, как выйти из режима bisect, не оставив репозиторий на чужом коммите. Курс показывает и случай, где bisect ошибается: нестабильный тест и слияния веток.
Базовые команды: git add, commit, status, log, создание и слияние веток.
Работа в терминале Linux на уровне cd, ls, cat, редактирование файла любым редактором.
Знать, что такое push и pull. Углубляться в удалённые репозитории заранее не нужно: модуль о них есть в курсе.
Сервер ничего не сообщает: прежние коммиты остаются в его хранилище, но ни одна ветка на них не указывает. Признак один: push внезапно отклоняется, а git status показывает расхождение там, где его не было.
Вы находите потерянную вершину в журнале origin/main или в клоне коллеги, возвращаете её через force-with-lease, который не затрёт чужую работу, и включаете на сервере защиту receive.denyNonFastForwards.
Одну и ту же беду чинят по-разному, смотря на то, ушли ли коммиты на сервер. Ключ в локальном коммите убирается правкой истории. Ключ в уже отправленной ветке требует ещё и чистки серверного репозитория: значения не должно остаться среди объектов нигде.
Rebase делает историю линейной, но меняет хеши. Поэтому опубликованную ветку после него заменяют через force-with-lease, а коллегу, успевшего запушить, это не затирает. Где проходит граница между безопасной правкой и опасной, вы определяете по состоянию репозитория, а не по заученному правилу.
Разработчики, которые боятся rebase и reset --hard и обходят их стороной
DevOps-инженеры, которым приходят с просьбой «верни, что пропало»
Те, кто уже пользуется Git каждый день, но разбирается с последствиями ошибок методом проб
В финале вы получаете репозиторий команды после недели без порядка. Удалена ветка hotfix с двумя коммитами. В истории лежит .env с боевым токеном. Коллега успел отправить два коммита в main, и ваш push отклоняется.
Подсказок нет: порядок действий выбираете сами. Проверка смотрит на результат: ветка на месте и опубликована, токена нет ни в одном коммите, история линейна, чужие коммиты целы. Любой путь, который приводит репозиторий в такое состояние, засчитывается.
Вы также можете задать любой вопрос по курсу у поддержки t.me/mentorix_support
Модулей: 5, уроков: 25. Задачи с кодом проверяются автоматически.
Стоимость курса: 1990 ₽