Зачем

9 уроков серии дают навыки по одному за раз в стерильных sandbox-репозиториях. В реальности проблемы наваливаются слоями: мусорная история и утекший секрет и merge-конфликт и два worktree в разных состояниях — всё одновременно.

Challenge — один заранее сломанный репозиторий с 10 такими проблемами. Вы проходите его руками и проверяете прогресс автоматическим скриптом.

Что внутри

Репозиторий собирается скриптом setup-challenge.sh из чистого состояния и содержит:

  1. Грязная история коммитов — сообщения fix, oops, update stuff (урок 1)
  2. Потерянный коммит в reflog — кто-то сделал reset --hard, в рабочем дереве его нет (урок 2)
  3. Merge-конфликт в одном файле от трёх веток (урок 3, урок 4)
  4. Активная ребейс-цепочка, прерванная на конфликте — нужно продолжить или отменить (урок 4)
  5. API-ключ и приватный RSA в истории — нужно вычистить и подстраховаться хуком (урок 5)
  6. Серия из пяти WIP-коммитов перед merge — нужен rebase -i squash (урок 4)
  7. Регрессия в 20 коммитах — ищется bisect’ом за 5 шагов (урок 6)
  8. Коммит из чужой ветки нужен в вашей — cherry-pick с конфликтом + rerere запомнит решение (урок 7)
  9. Параллельная задача без потери WIP — решается worktree (урок 8)
  10. Старый хлам в .git/worktrees/ — осиротевшие записи, нужен worktree prune (урок 8)

Задачи идут с нарастающей сложностью. P1–P6 покрывают базу (уроки 0–5), P7–P10 используют продвинутые инструменты (уроки 6–8).

Как начать

# 1. Клон репозитория челленджа
git clone https://github.com/devitway/git-master-challenge.git
cd git-master-challenge

# 2. Скрипты исполняемыми
chmod +x *.sh

# 3. Создать сломанный репо
./setup-challenge.sh

# 4. Войти в него
cd broken-enterprise-repo

# 5. Оценить текущее состояние
git status
git log --oneline -10
git branch -a

Каждый раз, когда думаете, что одну проблему починили — из корня git-master-challenge/:

./check-fixes.sh

Скрипт пробегает все 10 проверок и печатает, что зачтено, а что нет.

Требования к окружению

git --version          # 2.25+
bash --version         # 4.0+
node --version         # нужен для теста bisect (P7)

Git LFS и GitHub CLI — не нужны. Всё решается стандартным git + bash + node.

На что смотреть по ходу

  • Один коммит — одна проблема. Не чините пятью сразу — потом не восстановите цепочку мысли, и код-ревью превратится в ад.
  • git status после каждой операции. Особенно в середине rebase или bisect: легко забыть, где вы, и сделать commit, когда нужно rebase --continue.
  • Reflog — ваша страховка. Если что-то пошло не так, git reflog покажет все HEAD-позиции за последние 90 дней. Восстановить почти всегда можно (урок 2).
  • Не используйте --force по умолчанию. Если алгоритм требует force — в 90% случаев вы не дописали операцию: либо не сделали --continue, либо не add‘нули разрешённые конфликты. Притормозите.

Что это даёт

Не баллы, не «сертификат Git Master». Вы увидите, как накапливается git-долг в реальной команде, и выработаете рефлексы: какой инструмент применить в какой ситуации, где остановиться и не усугубить, где безопасно отступить через reset --hard ORIG_HEAD.

После Challenge 10-секундные git-ситуации перестают быть 10-секундными:

  • «нужно перенести один коммит» — рука сама тянется к cherry-pick, не к «перепишу заново»
  • «надо параллельно фичу и хотфикс» — рука к worktree add, не к stash с риском потерять его среди 20 других
  • «регрессия появилась за последние две недели» — git bi HEAD~100 ./test.sh против «давайте перебирать руками»

Что дальше

  • Ваши заметки по решениям — файл SOLUTIONS.md в своём форке репозитория. Через полгода вы вернётесь и обнаружите, что те же проблемы всплывают в других проектах. Личный справочник обгоняет любой общий курс.
  • Системно с нуля → «Курс молодого бойца» DevIT Academy — git в контексте Linux, Docker, Kubernetes и CI/CD, как рабочий поток, а не набор команд.
  • Обратная связь — если нашли косяки в условии или check-fixes.sh даёт ложный позитив, issue на GitHub или письмо в @DevITWay.

Серия целиком