Цель урока После урока вы умеете создать feature-ветку и слить её в main двумя разными способами (fast-forward и --no-ff), читаете git log --graph, понимаете разницу между тремя стратегиями merge (ff / no-ff / squash) и решаете merge-конфликт по маркерам <<<<<<< ======= >>>>>>>. Параметр Значение Bloom Применение SFIA Уровень 3 Время 40 минут Артефакт ~/.gitconfig с merge.ff = false, merge.conflictStyle = diff3, alias graph Проверка git log --graph показывает два merge-коммита с разной формой; конфликт решён Теория за 3 минуты Ветка в Git – это указатель на коммит. Не копия, не папка, не «параллельный мир». Одна строчка в файле .git/refs/heads/main с SHA. ...

Архитектура интеграции graph TB A[Пользователь] B[Vault Server] C[FreeIPA LDAP] A -->|1. Логин| B B -->|2. Проверка| C C -->|3. OK| B B -->|4. Token| A A -->|5. Секреты| B Процесс аутентификации: Пользователь вводит LDAP учётные данные Vault запрашивает FreeIPA LDAP FreeIPA проверяет учётные данные Vault выдаёт токен доступа Пользователь работает с секретами Серия статей: все части Установка FreeIPA NFS + Autofs интеграция Hashicorp Vault интеграция (эта статья) Требования Компонент Требования FreeIPA Настроен и работает (часть 1) Vault Server Linux, 2GB RAM Клиенты Vault CLI Сеть Доступ к FreeIPA:389 Часть 1: Установка Vault Установка на RHEL/CentOS # Репозиторий HashiCorp dnf config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo # Установка dnf install -y vault # Проверка vault --version Конфигурация Vault mkdir -p /etc/vault.d mkdir -p /opt/vault/data cat > /etc/vault.d/vault.hcl << 'EOF' # Vault конфигурация для интеграции с FreeIPA storage "file" { path = "/opt/vault/data" } listener "tcp" { address = "0.0.0.0:8200" tls_disable = 1 } api_addr = "http://192.168.1.30:8200" ui = true EOF chown -R vault:vault /opt/vault /etc/vault.d chmod 640 /etc/vault.d/vault.hcl Важно: tls_disable = 1 только для лаборатории! В production используйте TLS! ...

В предыдущих сериях: Qdrant (1/N), эмбеддинги (2/N), нарезка на чанки (3/N), гибридный поиск (4/N). Нужный чанк стабильно залетает в top-15. Но порядок внутри этих 15 результатов определяет, какой чанк окажется в top-1. А top-1 – это то, что видит пользователь (или LLM при генерации ответа). Этот пост о том, как заставить систему вчитываться в результаты. Переранжирование: дешёвый двухступенчатый каскад, который не меняет recall, но переставляет результаты так, чтобы лучший оказывался первым. Проблема: RRF не читает документы Гибридный поиск (пост 4/N) работает так: ...

Цель урока После урока вы умеете перестроить feature-ветку поверх свежего main через git rebase, понимаете разницу между rebase и merge на уровне графа, используете rebase -i для чистки коммитов перед PR (squash / reword / drop) и знаете золотое правило: не ребейсить то, что уже запушено в публичную ветку. Параметр Значение Bloom Применение, частично Анализ SFIA Уровень 3 Время 45 минут Артефакт ~/.gitconfig с pull.rebase = true, rebase.autoStash = true, alias rb, rbi Проверка Feature-ветка успешно ребейзнута поверх main; git log --graph показывает линейную историю Теория: rebase – это не merge git merge соединяет две ветки merge-коммитом, сохраняя факт ветвления: ...

В предыдущих сериях: Qdrant (1/N), эмбеддинги (2/N), нарезка на чанки (3/N), гибридный поиск (4/N), переранжирование (5/N). Конвейер (pipeline) – вся цепочка от запроса до ответа – построен и работает. Но насколько хорошо? Пока нет цифры, оценка "хорошо" остаётся субъективной. Повод для замера: проект AgentMemory заявляет 95.2% recall@5 на бенчмарке LongMemEval-S. Recall@5 (полнота поиска) – это доля вопросов, для которых нужный фрагмент попал в первую пятёрку результатов. Решил проверить эту цифру у себя: прогнал тот же метод через свой конвейер, но на реальных данных. ...

Цель урока После урока вы умеете написать и установить 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) ...

Сказ о 12 мегапикселях и потерянном времени Пользователь Татьяна пытается скормить нашему AI-сервису фото со своего айфона. Картинка обычная: весит около 5 МБ, разрешение – 12 мегапикселей. Татьяна жмет кнопку "Сгенерировать" и видит лаконичную заглушку: "Что-то пошло не так". Вторая попытка с другим стилем дает тот же результат. Естественно, у девелоперов на локалках и тестовых стендах всё летает. Баг воспроизводится только у Татьяны и только на её конкретном файле. Мы открываем логи в надежде сразу всё починить, но там нас встречает классическая заглушка: ...