Цель урока После урока вы умеете написать и установить pre-commit и commit-msg hook на чистом bash (без Husky / Node / Python), понимаете почему hooks живут локально и как распространить их на команду через core.hooksPath + папку в репозитории. Можете добавить проверку секретов, trailing whitespace, формата Conventional Commits. Параметр Значение Bloom Применение SFIA Уровень 3 Время 40 минут Артефакт repo/.githooks/pre-commit + commit-msg + core.hooksPath = .githooks Проверка Коммит с секретом блокируется; коммит с кривым сообщением блокируется; git commit --no-verify обходит (и это ожидаемо) Теория: что такое git hook Hook — это исполняемый файл в папке .git/hooks/, который Git вызывает на определённое событие. Если файл есть и имеет бит +x — Git запустит его и смотрит на exit code: 0 — продолжить операцию, не 0 — отменить. ...

Цель урока После урока вы умеете найти коммит, внёсший регрессию, за log₂(N) шагов через git bisect; различаете bad, good, skip; умеете автоматизировать поиск через git bisect run с любым тест-скриптом. Параметр Значение Bloom Применение, Анализ SFIA Уровень 2–3 Время 30–40 минут Артефакт test-bisect.sh — тест-детектор под bisect run Проверка Мини-тест + сценарий «найди виновника за 4 шага» Теория за 3 минуты Git-история — это DAG коммитов. Каждый коммит знает, от какого родителя он произошёл. ...

Цель урока После урока вы умеете переносить отдельные коммиты между ветками через cherry-pick, различаете случаи, когда это уместно, и когда правильнее merge/rebase. Включили rerere глобально и понимаете, как Git запоминает ваше решение конфликта, чтобы применить его автоматически в следующий раз. Параметр Значение Bloom Применение, Анализ SFIA Уровень 2–3 Время 35–45 минут Артефакт rerere.enabled = true в ~/.gitconfig + алиас pick Проверка Мини-тест + сценарий с повторным конфликтом Теория за 3 минуты git cherry-pick <sha> берёт один коммит с одной ветки и применяет как новый коммит на текущую. Новый коммит имеет другой SHA, но тот же diff и то же сообщение. ...

Цель урока После урока вы умеете создавать параллельные рабочие деревья через git worktree, держать в них разные ветки одновременно, убирать их и чистить мёртвые ссылки через prune. Понимаете, что объекты и refs лежат в одном .git/, а HEAD и index — своё для каждого дерева. Параметр Значение Bloom Применение, Анализ SFIA Уровень 2–3 Время 25–35 минут Артефакт Алиасы wta/wtl/wtr + конвенция ~/code/<repo>/ + <repo>-<ветка>/ Проверка Мини-тест + параллельная работа feature + hotfix без stash Теория за 3 минуты Обычный репозиторий выглядит так: один каталог my-repo/, внутри .git/ с объектами и refs, рядом ваши файлы. В каждый момент времени checked out одна ветка — это ваш HEAD. ...

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

Основные подходы к наблюдаемости Метод USE (Utilization, Saturation, Errors) Метод USE (Утилизация, Насыщенность, Ошибки) предложен Брэнданом Греггом как способ системно проверять “здоровье” ресурсов инфраструктуры (CPU, память, диск, сеть и пр.) (brendangregg.com) Идея проста: для каждого ресурса отслеживай три аспекта: Utilization (утилизация) — сколько времени ресурс занят полезной работой (в процентах). Saturation (насыщенность) — имеются ли очереди задач, ждут ли они доступ к ресурсу. Errors (ошибки) — сколько операций завершилось с ошибкой или сбоем. Этот подход помогает быстро выявлять “узкие места” на уровне оборудования или базовых систем, даже когда ты не знаешь заранее, где может быть проблема. (brendangregg.com) ...

В феврале Qwen Code выглядел как бесплатная альтернатива Claude Code. 15 апреля Alibaba закрыла бесплатный доступ. Инструмент устарел за два месяца. Это типичная проблема: привязка к одному вендору = риск. Сегодня бесплатно, завтра – нет. Поэтому перезапускаем тему с другим фокусом: tool-agnostic + model-agnostic. Выбираем CLI отдельно, модель отдельно, и собираем рабочий стек, который не сломается от решений чужого менеджмента. Часть 1: Выбираем CLI Три рабочих варианта на май 2026. Все – open-source, все работают с локальными моделями через Ollama. ...

БОЛЬ Go-приложение. Бинарник – 10MB, статически слинкован, без зависимостей. docker images показывает 900MB. Внутри образа: весь Go SDK (500MB), git, gcc, make, исходники, кеш сборки. Ничего из этого не нужно в production. 900MB на каждый микросервис, 12 сервисов – это 10.8GB на ноду. При деплое скачивается 900MB на каждый pod restart. Rollout занимает минуты вместо секунд. Multi-stage build решает проблему: один этап для сборки, другой – для запуска. В финальный образ попадает только бинарник. ...

БОЛЬ Ревью Docker-образа перед деплоем. docker images показывает 2.1GB для простого Node.js-приложения. Запускаете docker run --rm myapp ls -la и видите: node_modules (800MB), .git (400MB), test-data (500MB). И самое страшное – .env с DB_PASSWORD, JWT_SECRET, AWS_SECRET_KEY. Образ уже в Docker Hub. Пароли в открытом доступе. Даже если удалить .env в следующем слое – он останется в истории образа. docker history покажет всё. Исправление: .dockerignore – файл-фильтр, который не пускает лишнее в контекст сборки. ...

БОЛЬ CI pipeline: 47 коммитов в день, каждый запускает docker build. Сборка занимает 8 минут, из них 7 – npm ci. Вы поменяли одну строку в src/index.ts, но Docker заново устанавливает все 1200 зависимостей. Каждый. Раз. За день это 47 * 7 = 329 минут впустую. За месяц – 110 часов ожидания. И всё потому, что COPY . . стоит перед RUN npm ci. КАК УСТРОЕНО Docker собирает образ слоями. Каждая инструкция FROM, COPY, RUN создаёт слой. Слои кешируются. ...

БОЛЬ Джуниор присылает в чат: “У меня всё работает”. Вы клонируете репозиторий, запускаете npm install – ошибка. У него Node 18, у вас Node 22. У него Ubuntu, у вас macOS. У него python3 указывает на 3.10, у вас – на 3.12. “Работает у меня” – это не баг, это отсутствие воспроизводимой среды. Dockerfile решает проблему: он описывает среду декларативно. Кто бы ни собрал образ – результат будет одинаковый. КАК УСТРОЕНО Dockerfile – это текстовый файл с инструкциями для сборки образа. Каждая инструкция создаёт слой (layer) в образе. ...

БОЛЬ Пятница, 18:47. Вы обновляете Python на сервере, где крутятся 5 микросервисов. apt upgrade python3 – и бот в Telegram падает, потому что ему нужен Python 3.10, а вы только что поставили 3.12. Заодно сломался Flask-сервис, который зависел от libssl1.1, а теперь стоит libssl3. Знакомо? Это классика: конфликт зависимостей на общем хосте. Один apt update может положить всё, потому что 5 сервисов делят одну файловую систему, одни библиотеки, один Python. ...