Flatpak Builder — инструмент для разработчиков и сопровождающих Linux-приложений: он собирает их в пакеты формата Flatpak. Версия flatpak-builder 1.4.11 вышла 12 сентября. В ней полностью отключили Git-хуки при применении патчей. Изменение связано с уязвимостью CVE-2026-86320. Также разработчики исправили проблему GHSA-484h-v688-jq5j, из-за которой источник мог выйти за пределы base_dir в режиме песочницы.

Кроме того, flatpak-builder теперь раньше прерывает обработку некорректных контрольных сумм для архивов и файлов, проверяет наличие URL при разборе источников bzr и svn и пропускает уже перенесённые записи при миграции локалей.

Что делать

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

Источники

• Release 1.4.11 · flatpak/flatpak-builder · GitHub

Для тех, кто уже пользуется jj, это закрывает самую неприятную бытовую проблему инструмента, а два ломающих изменения в том же релизе стоит проверить сразу после обновления: команды jj config с флагом --user больше не спрашивают, какой файл править, а jj git import перестал подтягивать коммиты из отсоединённого HEAD в репозиториях без совмещения с Git. Предыдущая версия 0.44.0 выходила 6 августа, релизы у проекта идут примерно раз в месяц.

• jj converge заменяет две и больше видимых ревизии одного change ID одним коммитом; потомки перебазируются на решение, локальные закладки переезжают сами.
• Если эвристики не уверены, команда задаёт вопросы: слить описания, выбрать родителей, редко выбрать автора; в режиме --no-interactive операция прерывается, если нужен вопрос пользователю.
• Ломающее: jj config edit/set/unset --user теперь правит первый загруженный пользовательский конфиг, для точного выбора файла добавлен --file ПУТЬ.
• Ломающее: jj git import в неколоцированных репозиториях больше не импортирует коммиты с отсоединённого Git HEAD.
• Git HEAD теперь хранится отдельно для каждого worktree, существующие репозитории мигрируют автоматически; исправлен баг с duplicateEntries в git fsck после git add.

Откуда в jj берутся расходящиеся коммиты

В jj у каждого изменения есть постоянный change ID, который переживает перезапись коммита: можно поправить старый коммит в середине стека, и потомки перебазируются автоматически. Расхождение, или divergence, возникает, когда одно и то же изменение оказалось переписано дважды по разным веткам истории операций. Типичный сценарий: правка в двух рабочих пространствах, откат через jj undo после того, как часть работы уже ушла дальше, или неудачный конфликт при синхронизации с удалённым Git-репозиторием. В логе это выглядит как два коммита с одинаковым change ID, и до 0.45 их приходилось сводить руками через jj abandon, jj squash и jj rebase.

Что делает jj converge на самом деле

По описанию команды в исходниках, jj converge берёт ревизии из аргумента --revisions или из настройки revsets.converge, группирует их по change ID и считает расходящимися те группы, где ревизий больше одной. Если расходящихся изменений несколько, команда спросит, какое сводить. Дальше она применяет эвристики, чтобы собрать новую ревизию, а если те дали неоднозначный результат, задаёт вопросы: объединить ли описания, каких родителей выбрать и, в редких случаях, кого считать автором.

Когда решение найдено, новая ревизия заменяет расходящиеся, потомки перебазируются на неё, а локальные закладки, указывавшие на любую из старых версий, переезжают на новую. Два ограничения авторы оговаривают прямо. Во-первых, сводятся только ревизии, попавшие в revset: если у того же change ID есть видимые версии вне выборки, расхождение уменьшится, но не исчезнет. Во-вторых, в результате могут появиться файловые конфликты, даже если до этого их не было. Проверить, что именно сделала команда, можно через jj op show -p, посмотреть историю изменения через jj evolog, а откатить всё одним jj undo.

Режим --no-interactive нужен для скриптов и хуков: если без вопроса не обойтись, команда не зависнет в ожидании ввода, а прервётся с предупреждением.

Что сломается после обновления

Первое ломающее изменение касается конфигов. Раньше jj config edit --user, set --user и unset --user при нескольких пользовательских файлах, например ~/.config/jj/config.toml плюс каталог conf.d/, спрашивали, какой файл править. Теперь они молча берут первый загруженный. Если у вас конфиг разложен по нескольким файлам, нужный указывается явно:

Второе касается репозиториев, где jj живёт рядом с Git, но не в колоцированном режиме, то есть .jj и .git не делят один рабочий каталог. jj git import в них больше не импортирует коммиты с отсоединённого Git HEAD. Если рабочий процесс опирался на то, что jj подхватит коммит, сделанный в Git в состоянии detached HEAD, теперь такой коммит нужно закрепить веткой или тегом на стороне Git.

Внутреннее изменение, которое тоже стоит знать: состояние Git HEAD теперь хранится отдельно для каждого worktree. Это подготовка к поддержке нескольких Git worktree в колоцированных репозиториях, когда у каждого рабочего пространства jj свой HEAD. Существующие репозитории мигрируют автоматически при первом запуске новой версии.

Исправления, которые заметят те, кто уже обжигался

• В колоцированных репозиториях git add после команды jj больше не оставляет в индексе устаревший cache-tree, из-за которого git fsck ругался на duplicateEntries. Уже испорченные репозитории исправление не лечит.
• Ctrl+C в пейджере less теперь выходит чисто: во флаги по умолчанию добавили -K, раньше терминал мог остаться в raw-режиме с мусором из escape-последовательностей.
• Сторона конфликта, оканчивающаяся на символ возврата каретки, больше не теряет этот байт при повторном разборе материализованного конфликта.
• jj run останавливается на первой ревизии, где процесс завершился с ненулевым кодом, вместо того чтобы идти дальше.
• Набор immutable_heads() по умолчанию теперь включает untracked_remote_tags(); jj bisect предупреждает, когда из-за пропусков не может однозначно назвать первую плохую ревизию; починен краш jj log на скрытых ревизиях с revset log-graph-prioritize.

Как обновиться

Готовые сборки для Windows, macOS и Linux лежат на странице релиза, вариант с musl должен работать на любом дистрибутиве. По документации установить последний релиз можно так:

Кому обновление ничего не изменит: тем, кто держит jj в одном файле конфига и работает только в колоцированных репозиториях. Им достанется jj converge и исправления, а ломающие изменения не затронут. Следующий сигнал, за которым стоит следить, это планируемая поддержка нескольких Git worktree, под которую в 0.45 подготовили хранение HEAD.

Источники: Релиз jj v0.45.0 на GitHub, Документация: установка и настройка jj 0.45, Исходник команды converge (описание в cli/src/commands/converge.rs)

Изображение на обложке: Логотип: J. Jennings, CC BY 4.0

DoltLite запустили 25 марта 2026 года как замену SQLite, у которой вместо B-tree под капотом content-addressed Prolly Tree. Всё остальное, по описанию основателя DoltHub Тима Сена, от SQLite: парсер SQL, анализатор, файловый слой и тестовый harness. До беты ушло около 2000 pull request и пять месяцев.

• DoltLite 0.50.0 объявлен бетой: стабильный формат хранения, SQL-совместимость и полный набор операций контроля версий.
• Поддерживаются branch, merge, diff, rebase, cherry-pick, reset, а также push, pull, clone и fetch на свой remote или DoltHub.
• Из 892 277 TCL-тестов SQLite проходят 99,46%; sqllogictest на 5,8 млн запросов проходит полностью; известно 4809 расхождений.
• В памяти чтение медленнее SQLite на 10%, запись на 60%; для файловых баз чтение на уровне SQLite, пакетная запись медленнее на 10%.
• Мелкие autocommit-записи медленнее в 3,1 раза: около 400 мкс против 125 мкс у SQLite.

Что «бета» означает у DoltHub

Компания перечисляет четыре условия. Стабильный формат хранения: до беты он менялся 12 раз, а текущий вариант продержался 57 релизов, больше трёх месяцев, и для будущих несовместимых изменений обещан путь миграции. SQL-совместимость: DoltLite проходит 100% sqllogictest, это 5,8 млн запросов, и 99,46% из 892 277 TCL-тестов самого SQLite. Полный контроль версий: ветки, слияния, diff, rebase, cherry-pick, reset и удалённые операции. И производительность, пригодная для production, с оговорками ниже.

Оставшиеся 4809 расхождений с SQLite DoltHub объясняет архитектурой: отказ от rowid, chunk вместо page и отсутствие WAL и journal-файлов рядом с базой. Если код полагается на эти детали SQLite, миграция не будет прозрачной; проверить стоит именно их.

Сколько стоит версионирование

Замеры приводит сам вендор. Для базы в памяти чтение медленнее SQLite примерно на 10%, запись примерно на 60%. Для файловой базы чтение на уровне SQLite, пакетная запись медленнее примерно на 10%. Хуже всего мелким autocommit-транзакциям: каждая такая запись занимает около 400 мкс против 125 мкс у SQLite, то есть в 3,1 раза дольше. Причина в природе Prolly Tree: каждое изменение порождает новые chunk с хешами, и на одиночной вставке эта работа не амортизируется.

На практике это значит, что DoltLite подходит для сценариев, где данные меняются пакетами и важна история: конфигурации, справочники, наборы данных для ML, локальные базы в приложениях, где нужен откат и сравнение версий. Для очереди с тысячами мелких вставок в секунду SQLite по-прежнему быстрее, и вендор этого не скрывает.

Что можно сделать уже сегодня

Рабочий цикл похож на Git: создать ветку, изменить данные, посмотреть diff, слить. Удалённые операции push, pull, clone и fetch работают с собственным remote или с DoltHub. 7 августа DoltHub добавила поддержку DoltLite в Dolt Workbench, свой графический клиент, где ветвление, diff и merge доступны из интерфейса.

Сборки, по данным репозитория, есть для Linux, macOS, Windows, Python, Node.js, Rust, Android и WebAssembly. Лицензия в анонсе беты не указана, и перед использованием в коммерческом продукте её стоит уточнить в репозитории.

Релиз 0.50.0 не содержит изменений кода относительно 0.11.57: номер версии подняли, чтобы обозначить бету. Если вы уже на 0.11.57, обновляться ради кода не нужно.

Контекст

DoltHub с 2018 года развивает Dolt, версионируемую базу, совместимую с MySQL. DoltLite переносит ту же идею на встраиваемый движок: Prolly Tree даёт дешёвое сравнение версий по хешам и структурное слияние, а SQLite даёт зрелый SQL-слой. По нашей оценке, главный практический вопрос беты не в фичах, а в том, насколько быстро проект закроет разрыв в мелких записях: именно там пройдёт граница между «база для датасетов» и «замена SQLite в приложении».

Сроков выхода стабильной версии DoltHub не называет; редакция проверит, изменится ли производительность записи в следующих релизах.

Источники: Блог DoltHub: DoltLite Beta, Релиз v0.50.0 на GitHub

Для тех, кто пишет багрепорты из скриптов, собирает отчёты в CI или просто не хочет переключаться в браузер ради одной картинки, это закрывает давний разрыв между «вот команда, которая падает» и «вот как это выглядит». Единственное серьёзное исключение: GitHub Enterprise Server в этом релизе не поддерживается.

• Флаг --attach работает в gh issue create, edit, comment и в gh pr create, edit, comment; его можно повторять несколько раз.
• Форматы: PNG, JPEG, GIF, WebP, SVG для картинок и MP4, MOV, WebM для видео.
• Лимит на изображение и GIF 10 МБ; видео до 10 МБ на бесплатном плане и до 100 МБ на платных.
• Нужен OAuth-токен от gh auth login или classic personal access token и право записи в репозиторий.
• GitHub Enterprise Server не поддерживается; нужна версия gh 2.99.0.

Как это выглядит в командной строке

Минимальный пример из changelog: приложить скриншот к комментарию в issue.

Флаг повторяемый, поэтому к одному issue можно приложить сразу несколько файлов, указав --attach для каждого. Alt-текст задаётся после пути через решётку: --attach './login.png#The login error state'. Это тот же alt, который потом увидят читатели со скринридером, так что писать его стоит осмысленно.

Самая полезная деталь спрятана в обработке Markdown. Если в тексте issue или комментария уже стоит локальная ссылка вида , CLI перепишет её на адрес загруженного файла. Вложения, на которые в тексте ссылок нет, добавляются в конец Markdown. Значит, можно писать описание бага в редакторе с относительными путями к картинкам, а потом одной командой отправить и текст, и файлы.

Ограничения, о которых стоит знать заранее

Для загрузки нужен либо OAuth-токен, полученный через gh auth login, либо classic personal access token; другие типы токенов в changelog не упомянуты, и это стоит учитывать в CI. Кроме того, требуется право записи в репозиторий: приложить файл к чужому issue в проекте, где вы не участник, не получится, даже если оставлять комментарии там можно.

Лимиты размеров: 10 МБ для изображений и GIF, для видео 10 МБ на Free и 100 МБ на платных планах. GitHub Enterprise Server новую возможность не получил; сроки для самостоятельно развёрнутых инсталляций в публикации не названы.

Что ещё не сказано: как ведёт себя команда при превышении лимита, поддерживает ли она загрузку по URL вместо локального файла и когда флаг доберётся до gh release. Судя по тексту changelog, речь только об issue, pull request и комментариях.

Где это пригодится

• Тестовые пайплайны: упавший end-to-end тест прикладывает скриншот или запись браузера к автоматически созданному issue.
• Ревью интерфейсов: gh pr comment --attach с записью экрана вместо описания «нажмите сюда, потом сюда».
• Скрипты отчётов: график из matplotlib или диаграмма сборки уходит в комментарий к pull request без промежуточного хостинга.

Обновиться можно штатным способом: через менеджер пакетов, которым gh ставился, или скачав релиз 2.99.0 с GitHub.

Редакция проверит, появится ли поддержка Enterprise Server в следующих релизах gh.

Источник: Changelog GitHub: GitHub CLI media in issues, pull requests, and comments

Изображение на обложке: GitHub

В AutoGPT, где на момент интервью у репозитория было свыше 180 тысяч звёзд и 150 открытых PR, большая часть этих PR создана агентами: Copilot, OpenClaw, собственными инструментами команды и сторонними ботами. Большинство мейнтенеров реагируют просто: закрыть дверь, отключить пулреквесты, не тратить силы на чужой LLM-вывод. Но у Николаса Тиндла, одного из основателей ИИ-инженерии в AutoGPT, другой взгляд: «По сути, кто-то другой платит за ваши вычислительные ресурсы. Если контрибьютор хочет потратить свои токены на улучшение вашего проекта — пусть тратит. Главное, сделать так, чтобы единственный путь внутрь проходил через ваши правила.»

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

Агенты не ищут документацию сами — они читают то, что лежит рядом с кодом. AGENTS.md и CLAUDE.md в нужных директориях работают лучше, чем вики.

Пропускные ворота должны быть автоматическими и однозначными: шаблон PR, тест-план, CI как стена, CLA как детектор человека.

Не все ворота стоит оставлять включёнными: автоматические комментарии об ошибках CI быстро превращаются в шум.

Плохой AGENTS.md хуже, чем его отсутствие: избыточные инструкции засоряют контекст и ломают поведение агентов.

Мейнтенер всё ещё решает, что принимать: закрыть PR и переписать самому — тоже валидный выбор.

Проблема не в документации, а в её обнаружении

Первое, что пробовала сделать AutoGPT, — улучшить CONTRIBUTING.md, написать подробную вики и обновить гайды. Это не сработало. Дело в том, что агенты не ходят по ссылкам и не ищут документацию в разделах репозитория. Они смотрят на то, что находится в текущей директории и на один-два уровня выше. Если инструкция не лежит там, где агент работает, для него её не существует.

Сначала команда добавила файлы CLAUDE.md, потому что Claude открывал пулреквесты без достаточного контекста о репозитории. Потом выяснилось, что Copilot и Codex эти файлы игнорируют — они не Claude. Решением стал централизованный AGENTS.md, на который указывают все специфичные для модели файлы.

Важный нюанс: AGENTS.md действует внутри директории. Если агент работает в backend/, он видит правила для бэкенда. Если динамически загружается навык, связанный с фронтендом, агент может не знать, в какой директории искать инструкции — и навык сам должен ему подсказать путь. Поэтому в AutoGPT файл AGENTS.md лежит рядом с кодом, который он регулирует.

Навык — что это?
В терминологии агентских инструкций навык — это файл с описанием, по которому агент решает, когда загружать полный набор правил. Агент сканирует описания заранее и подключает нужный навык, когда задача совпадает. Например: «напиши Storybook-тест, если компонент лежит в этих папках».

Фронтенд-инженер AutoGPT устал от одного и того же класса сломанных PR в open source-проекте и оформил гайд как навык. Теперь каждый агент, который касается репозитория, видит триггер и выполняет правило. Бэкенд делает то же самое: не набрал 80% покрытия — PR не пройдёт.

Ворота для ИИ-контрибьюторов в open source

AutoGPT выстроила несколько механизмов, которые сдерживают поток низкокачественных пулреквестов и заставляют агентов вести себя предсказуемо.

Шаблон пулреквеста как пропускной пункт

В шаблоне PR прямо написано: PR, не соответствующий шаблону, закрывается автоматически и без колебаний. Команда даже построила бота, который это делает. Но запускать его не понадобилось — само правило изменило поведение агентов. Агенты стали заполнять шаблон. А вот люди иногда его игнорировали, и это Тиндл считает полезным сигналом: «Если вы не следуете шаблону, вы, скорее всего, человек, и я отнесусь к вам мягче.»

Тест-план, который запускает код

В шаблоне есть раздел тест-плана, и его формулировка незаметно подсказывает агенту протестировать пулреквест. Эта фраза активирует навык test PR: агент устанавливает браузер, разворачивает приложение и проверяет изменение. Агент пришёл поставить галочку, а в итоге запустил код. После этого сломанные PR стали редкостью. Осталась другая проблема — PR, которые работают, но не вписываются в дорожную карту.

CI — стена, а не рекомендация

Codecov и другие проверки настроены как required checks. Агент открывает PR, через несколько минут видит, что мёрж заблокирован, загружает навык с тестами и добивается покрытия. Никто не просил — инфраструктура сама направила агента.

CLA (Contributor License Agreement) как детектор человека

AutoGPT использует двойную лицензию, но Тиндл советует лицензионное соглашение участника (Contributor License Agreement, CLA) любому проекту, даже MIT. Подписание требует браузера и OAuth-потока GitHub на отдельном домене. Сегодня агенты с этим справляются плохо — и это хорошо, потому что большинство мейнтенеров не хотят, чтобы агент ходил в GitHub от их имени. Если CLA не подписан в течение недели, PR закрывается с комментарием «подпишите CLA и переоткройте».

SHA коммита перед закрытием замечания

Часть агентов закрывает все треды ревью, не исправляя код. В AutoGPT есть навык pr-address, который описывает допустимую последовательность: исправить, закоммитить, запушить, ответить, потом разрешить тред. Ответ должен содержать полный SHA коммита, полученный через git rev-parse HEAD, чтобы агент не подсунул старый хеш. Навык явно называет антипаттерны: «Acknowledged» — не исправление, и ссылка на коммит, который не трогает указанную строку, тоже не считается.

Ворота, от которых пришлось отказаться

Когда CI падает, AutoGPT изначально запускала агента, который читал лог и писал комментарий, что сломалось. Первая версия использовала Claude Code внутри GitHub Actions с аутентификацией в CI — лишняя широкая учётная запись. Потом перешли на Copilot внутри рабочего процесса: тот же результат, но без лишних кредов.

А потом выключили именно автоматические комментарии об ошибках CI. Прогоны в AutoGPT падают часто, и бот, который целыми днями описывает каждый падший прогон, создаёт не меньше шума, сколько и сами ошибки. Урок: оставляйте то, что снижает нагрузку на мейнтенера, и выключайте то, что превращается в фоновый шум.

Четыре ловушки, которые стоит записать

• Плохой AGENTS.md хуже, чем его отсутствие. В AutoGPT сначала разбросали файлы повсюду и засорили контекст. Если поведение агентов ухудшилось — перечитайте, что вы написали.
• GraphQL API GitHub быстро исчерпывает лимит запросов. Если каждый инструмент в команде ходит в CLI как отдельный пользователь, лимит закончится. Создайте GitHub App и аутентифицируйте CLI через неё.
• Сложное ревью стоит реальных денег. У AutoGPT PR проходит через клон ветки, восемь агентов с разными ролями, запуск стека и скриншоты. Круто, но дорого. Сейчас эту процедуру запускают только для совсем маленьких или крупных PR.
• Проверяйте авторизованные приложения. Каждый протестированный инструмент оставляет OAuth-разрешение. Если перестали использовать приложение — удалите его из настроек GitHub.

Не всё в open source решается воротами

Тиндл подчёркивает два тезиса, которые не связаны с инструментами. Первый: вы не обязаны принимать каждый пулреквест. Мёржить чужой LLM-вывод — асимметричная сделка: вы будете поддерживать этот код вечно. Закрыть PR и переписать решение самому — валидный выбор.

GitHub даёт мейнтенерам ручки: можно отключить пулреквесты целиком, ограничить создание issue только участникам с правами collaborator или требовать предварительного обсуждения. Если хотите — вообще закройте приём внешнего кода, как это сделали в SQLite: они принимают только баг-репорты. У вашего проекта тоже может быть своя граница.

Второй тезис: когда вы закрываете PR, но переписываете его идею сами, добавьте автора как соавтора, если это уместно. В AutoGPT 800 контрибьюторов, и один дополнительный соавтор ничего не стоит. Для большинства людей важно, что их проблему заметили и исправили.

Выводы

Open source развивался, делая сотрудничество явным: лицензии формализовали разрешения, issue сделали работу видимой, пулреквесты превратили ревью в общую практику. Инструкции для агентов в репозитории — следующий шаг в этом направлении. Правильная форма ещё не устоялась: у AutoGPT уже третья версия AGENTS.md, и она появилась потому, что команда сначала развёртывала плохие версии и смотрела, что с ними делают агенты.

Тиндл советует мейнтенерам записываться в программу обратной связи GitHub — maintainers.github.com:

You've got to go there. You've got to sign up. It gets you all the connections you want at GitHub. That's where I learned about all this stuff, and where I share it.

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

Если тема интересна, загляните в разделы tproger: open source, GitHub и искусственный интеллект.

Источник: GitHub Blog — Your contributors are AI-first now. Is your project?

Арендовать мощные VPS под ресурсоемкие задачи в текущих реалиях выходит неоправданно дорого. При этом дома у меня уже был выделенный неттоп (мини-ПК) с 16 ГБ оперативной памяти на базе энергоэффективного процессора Intel N95.

Пройдя путь от простых Bash-скриптов и сторонних туннелей до полностью автоматизированной инфраструктуры, я создал проект ServeHub-2. В этой статье я подробно разберу, как эволюционировала сеть проекта, почему декларативный подход победил императивный и с какими неочевидными багами пришлось столкнуться в процессе автоматизации.

История настройки сетевой архитектуры

Использование Tuna

В самом начале проекта я еще не думал о VPN как о способе пробития NAT и основе, на которой будет строиться вся система. Первое, к чему я пришел — сервис Tuna. Если кратко, это аналог Cloudflare Tunnel за условные 300 рублей. У него очень приятный веб-интерфейс и невероятно простая настройка. Однако для полноценной независимой архитектуры он не подошел по двум причинам:

• Сервера Tuna находятся вне контроля пользователя.
• На удаленном сервере нельзя развернуть свои сопутствующие сервисы.

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

Вот пример конфига для tuna (все максимально просто, создаем контейнеры для ssh туннеля, чтобы был доступ ssh, а также основной http туннель с привязкой к nginx или любому другому прокси если такой есть):

В поисках гибкости: тесты Pangolin и переход к FRP

После Tuna я решил двигаться в сторону собственного контроля и попробовал Pangolin. Однако решение быстро отвалилось: для дешёвого сервера оно оказалось слишком «тяжёлым» и избыточным. Главные минусы — ощутимый оверхед по ресурсам и лишний слой принудительной веб-аутентификации перед самими сервисами. Это ломало нормальное взаимодействие с родными мобильными клиентами (вроде Element для Matrix или Bitwarden для паролей), где повторная авторизация в браузере просто не нужна.

На смену пришел FRP (Fast Reverse Proxy). Он выполнял ту же функцию проброса, но хостил я его уже на собственном арендованном VPS в режиме Layer 4 (TCP). Это дало абсолютную гибкость: внешний VPS не заглядывал внутрь пакетов и ничего не расшифровывал, а просто пересылал сырой поток домой. Кроме того, это отлично оптимизировало расходы: вместо 300 рублей за Tuna и ещё 300 рублей за отдельный VPN, я стал платить всего 500 рублей за один стойкий VPS, который мог настраивать как хочу. (к тому же можно было обойтись даже дешевле, так как VPS с 4 гб оперативки загружен всего лишь на 40%, процессор всего на 20%-40%)

FRP состоит из 2 конфигурационных файлов (один на удаленном сервере frp server, другой на локальном frp client), все также довольно просто, однако его можно использовать на разных слоях. У меня он брал трафик за стандартный TCP и передавал его на локальный сервер.

Также доп. фишка в том что основная конфигурация происходит именно в frpc, который, в свою очередь, передает часть настроек на frp на удаленном сервере.

frpc.toml:

frps.toml:

Полноценный переезд на WireGuard (AmneziaWG) и 8 часов отладки

Со временем архитектура эволюционировала в сторону полноценной VPN-сети на базе WireGuard, а точнее — его модификации AmneziaWG. Причин для этого шага было несколько:

• Безопасность: FRP всё же открывал внутренние ресурсы в публичный интернет, оставляя их доступными для сканеров портов.
• Удобство маршрутизации: Все участники сети стали равноправными узлами в одной виртуальной локальной подсети. Больше не нужно было настраивать постоянные односторонние пробросы.
• Дополнительный бонус: Поскольку удаленный VPS был куплен в Нидерландах, через этот же VPN я автоматически получил безопасный доступ ко всем зарубежным ресурсам.

Для реализации схемы на удаленном VPS был развернут контейнер wg-easy с поддержкой AmneziaWG, а на домашнем мини-ПК — клиентский контейнер Amnezia (сборка из Dockerfile с использованием amnezia-tools и модулем ядра хоста).

И именно здесь я поймал самый изнурительный баг проекта. После развертывания трафик упорно шёл только в одну сторону. Часов 8 ушло на диагностику iptables, маршрутов и чтение зарубежных форумов (что бесполезно, учитывая специфику наших блокировок). Оказалось, провайдер просто дропал обратный трафик стандартного WireGuard, так как пакеты шли без маскировки. Причина крылась в docker-compose.yml: у меня было прописано image: ghcr.io/wg-easy/wg-easy:latest. Как выяснилось, тег latest на Docker Hub намертво прилип к старой 14-й версии, а поддержка параметров AmneziaWG появилась только в ветке 15.x. Изменение тега на конкретную версию (15.3) решило проблему за секунду.

Благодаря переходу конфигурация получилась максимально простой, основные отличия от стандартной документации выделил в коде: (в основном то, на что пришлось долго рыть информацию)

Настройка Nginx

Чтобы сервисы были доступны исключительно внутри подсети VPN, я задействовал Nginx. Доступ к приложениям был жестко ограничен на уровне конфигурации — веб-сервер принимает запросы только из диапазона IP-адресов 10.8.0.0/24. Любые попытки постучаться на сервер из внешнего интернета без активного VPN-туннеля автоматически сбрасываются Nginx.

Логика распределения завязана на proxy-протоколе: Nginx на удаленном VPS выступает основным входным узлом, принимает зашифрованный трафик, заворачивает его в заголовки с реальным IP-адресом клиента и через туннель перекидывает на локальный Nginx домашнего сервера. Локальный веб-сервер уже сам расшифровывает SSL и распределяет трафик по конечным Docker-контейнерам, сохраняя реальные IP в логах безопасности.

Вставлю один кусок кода из nginx на удаленной машине для примера, так все остальное примерно похоже (конфиги использовались в виде .template):

SSL-сертификаты

Для получения валидных SSL-сертификатов я настроил работу через автоматический Certbot по challenge-валидации DNS-01 c API Webnames. Сам домен привязан к внутреннему IP-адресу 10.8.0.1. Проверка через DNS позволила выпустить единый wildcard-сертификат на весь домен и его поддомены без необходимости держать открытым 80-й порт веб-сервера наружу.

Уточню, что certbot запускается автоматически во время выполнения Ansible плейбука, поэтому самому кроме указания переменных ничего делать не нужно.

В итоге получилась схема, при которой все сервисы доступны по красивым доменным именам с HTTPS, но абсолютно невидимы для внешнего интернета.

Вот настройка certbot:

История софта

Параллельно с сетевой структурой развивался и сам набор приложений. Изначально я хотел собрать в одном месте утилиты, которыми пользуюсь каждый день, но в процессе селфхостинга быстро понимаешь: нельзя просто накидать контейнеров и надеяться, что мини-ПК справится, а конфигурационные файлы не превратятся в кашу.

Первый стек и оптимизация

Первыми на домашнем сервере прижились медиа-сервисы: Navidrome для стриминга музыки и Audiobookshelf для аудиокниг и подкастов. Они легковесные, имеют отличные мобильные клиенты с синхронизацией прогресса и полностью закрывают мои потребности. Позже к ним добавился Nextcloud как единое независимое облако для файлов, контактов и семейных документов.

Затем встал вопрос безопасного хранения паролей. Сначала я смотрел в сторону оригинального Bitwarden, но в итоге я выбрал Vaultwarden — альтернативный сервер на Rust, полностью совместимый с API Bitwarden. Он потребляет считанные мегабайты оперативной памяти и работает идеально. Дополнительно для удобства управления всей этой распределенной Docker-инфраструктурой в локальный стек был добавлен Portainer. (+ Portainer Agent на удаленный сервер)

Из интересных моментов, где мне пришлось немного больше возиться, чем с остальными сервисами это nextcloud настройка:

Ошибки проектирования: почему я удалил Matrix (Synapse)

Не все решения прошли проверку временем. На этапе использования Tuna и FRP я развернул сервер Matrix (Synapse) для защищенного обмена сообщениями. Мне казалось это крутой идеей, но когда я окончательно перешел на AmneziaWG, целесообразность мессенджера внутри закрытого туннеля сошла на нет.

Synapse требовал слишком много ресурсов, впустую расходовал оперативку домашнего ПК и усложнял конфиг Nginx. При этом реальной пользы для семьи он не приносил. Для критических алертов инфраструктуры и повседневного общения проще и эффективнее оказалось использовать Telegram. (плюс алертинг настроен именно через него) В итоге я полностью выпилил Synapse из стека, освободив ресурсы.

Вместо него я добавил в связку к wg-easy локальный AdGuard Home. Теперь он работает прямо внутри VPN-сети: очищает весь трафик от рекламы и трекеров на лету, кэширует DNS-запросы и не дает истории веб-серфинга улетать внешним провайдерам.

Основной проблемой с которой я столкнулся при использовании AdGuard Home, так это то что я так и не понял как заставить использовать AmneziaVPN клиент AdGuard как основной DNS, при этом AmneziaWG работает прекрасно. Как я понимаю дело в том что AmneziaWG работает намного проще на уровне ip и у него нету никаких доп фильтров, настроек и подобного, поэтому он просто берет данные из конфига.

От костылей на Bash к декларативному Ansible

Весь стек на обоих серверах разворачивался через bash скрипты, что было уж очень плохо с точки зрения идемпотентности. Во первых из-за bash мне постоянно приходилось очищать сервера, так как нормальных проверок у меня не было и писать я их не хотел, а также было много костылей с импортом переменных, записями в файлы и подобным.

Так я пришел к декларативному подходу и Ansible. Теперь вся конфигурация описывается в виде плейбуков и ролей, отражающих конечное желаемое состояние серверов. Конфиденциальные данные перенесены в файл secrets.yml, а хрупкие конструкции автоматизированы через шаблоны Jinja2. Проект стал идемпотентным: если шаги уже выполнены, Ansible их просто пропускает.

В итоге получилось несколько yaml файлов для стандартной настройки системы (bootstrap_os.yml) и для настройки каждого из хостов (setup_local.yml и setup_remote.yml). В итоге теперь все что нужно чтобы полностью с нуля развернуть проект - скачать Ansible, несколько других зависимостей на свой рабочий пк и запустить один manage_deploy.sh, в котором можно будет выбрать сценарий как будет вести себя Ansible и спокойно дождаться разворачивания сервисов.

Также благодаря Ansible я удобно реализовал переносимость проекта. Так как я решил не использовать тома docker, и вместо этого храню все в папках, чтобы перенести старые данные проекта нужно просто скопировать папку apps-data и положить ее в нужное место и все само заработает после повторного развертывания проекта. В Ansible выделяется отдельная пауза для этого.

Вот пример основного плейбука deploy.yml:

Тестирование мультидистрибутивности с помощью Vagrant

Проект изначально затачивался под работу на трех дистрибутивах: Ubuntu, Debian и Arch Linux. Тестировать Ansible-плейбуки прямо на рабочей локальной машине (в моем случае — EndeavourOS) слишком рискованно, а создавать виртуальные машины руками — долго и неудобно.

Решением стал Vagrant, позволяющий за пару минут развернуть чистые ОС в VirtualBox из готовых образов. Но в процессе настройки мультивендорного стенда в режиме сетевого моста (public_network) всплыли две критические проблемы:

1. Конфликт DNS: По умолчанию Vagrant создает NAT-интерфейс для управления нодой. При включении второго (публичного) интерфейса для локальной сети ломался дефолтный DNS-резолвер. Проблему пришлось решать принудительной очисткой и перезаписью файла /etc/resolv.conf через inline-скрипт автоматизации Vagrant.
2. Проблема с GRUB на Debian: В используемом базовом образе generic/debian12 конфигурация GRUB сохраняла жесткую привязку к конкретному имени диска из окружения сборщика. При повторном развертывании плейбуков на тестовом стенде это приводило к сбоям загрузчика. Чтобы автоматизировать очистку, пришлось внедрить скрипт, который на лету определяет имя системного диска через lsblk и автоматически передает правильные параметры в загрузчик через утилиту debconf-set-selections.

Вот код Vagrantfile: (в node.vm.provision происходит основное решение ошибок)

Надежная система бэкапов на базе BorgmaticДля создания резервных копий я внедрил Borgmatic (удобную надстройку над дедуплицирующим инструментом Borg Backup). Весь процесс автоматизирован с помощью связки системных юнитов borgmatic.service и borgmatic.timer. В бэкап уходят две ключевые директории: apps-data (конфигурации приложений и баз данных) и PersonalData (медиатека: музыка, книги, подкасты, файлы Nextcloud).

Развертывание системы бэкапов полностью берет на себя Ansible. Мне достаточно указать UUID внешнего жесткого диска — скрипт сам проверит его наличие в системе, примонтирует в нужную директорию, создаст зашифрованный репозиторий и настроит политику ротации (хранение 7 ежедневных, 4 еженедельных и 6 ежемесячных копий). Также в Prometheus выведен мониторинг самого репозитория .borg для отслеживания его размера и статуса успешности архивации.

Главная проблема при бэкапе работающих Docker-контейнеров — риск скопировать базу данных в «битом» или неконсистентном состоянии, если в момент создания архива в нее шла активная запись. Чтобы решить эту проблему, я задействовал механизм хуков в конфигурации Borgmatic.

Перед началом резервного копирования автоматически срабатывает команда остановки контейнеров проекта (docker-compose down), а после успешного завершения (или в случае возникновения непредвиденной ошибки) контейнеры автоматически поднимаются обратно в фоновом режиме. Для удобного просмотра архивов и быстрого восстановления файлов я развернул веб-интерфейс Borg UI.

Конфигурация borgmatic: (использую как Jinja2 шаблон, чтобы Ansible в плейбуках сам подставил переменные)

Наблюдаемость (Observability) уровня Enterprise

В последних релизах (v1.2.0 и v1.3.0) фокус проекта сместился на мониторинг и работу с логами.

Эволюция алертинга и переход на Gatus

Изначально для мониторинга доступности я смотрел на Uptime Kuma, но отказался из-за отсутствия удобной декларативной настройки через конфиги. Затем я развернул связку Blackbox Exporter и Alertmanager с уведомлениями в Matrix. Но тут крылась логическая несостыковка: весь алертинг был завязан на локальном ПК, и в случае его аппаратного отказа я бы просто лишился уведомлений.

Тогда я решил вернуть Uptime Kuma, но развернуть его на удаленном VPS в качестве внешнего «сторожа» и автоматизировать его настройку через Python-скрипт с библиотекой uptime-kuma-api. Но и тут ждали «грабли» — библиотека не обновлялась три года и намертво ломалась на свежих версиях Kuma.

В итоге идеальным решением стал Gatus. Он изначально проектировался под управление через YAML-конфиги и поддерживает отправку алертов, если сервер не отвечает. Из-за специфики фронтенда Gatus (он не умеет работать из подкаталога типа /gatus), мне пришлось перенести его и wg-easy на полноценные субдомены gatus. и wireguard.

Для Gatus получился простой конфиг:

Для мониторинга аппаратных ресурсов удаленного и локального серверов была развернута связка node-exporter + cAdvisor. Все уведомления теперь приходят мгновенно в Telegram-бота. Чтобы избежать лавины одинаковых сообщений (например, при перезагрузке хоста), в Alertmanager настроена жесткая группировка и дедупликация событий. Также добавлен экспортер для AdGuard Home, выводящий статистику заблокированных запросов в Grafana.

Централизованные логи: Loki + Grafana Alloy

В релизе v1.3.0 в стек была добавлена централизованная система сбора логов Loki. Вместо устаревшего Promtail в качестве агента сбора я применил Grafana Alloy.

Он эффективно собирает логи со всех запущенных Docker-контейнеров, парсит их и передает в Loki. Теперь вся история событий, ошибок веб-сервера Nginx или падений внутренних приложений доступна в едином интерфейсе Grafana с возможностью удобной фильтрации через LogQL, что значительно упрощает отладку.

Конфиг Loki:

Конфиг Grafana Alloy: (локальный конфиг)

Интерфейс: переход на Homepage

Изначально для домашней страницы я написал кастомную минималистичную HTML-панель с Glassmorphism-дизайном. Выглядело это красиво, но добавлять новые сервисы вручную через постоянную правку исходного кода было крайне неудобно.

В итоге я заменил самописную страницу на полноценный комьюнити-проект Homepage. Это дало некоторую гибкость: вся панель настраивается через простые YAML-файлы и поддерживает встроенные виджеты интеграции. Пока что она простенькая, но возможно в будущем сделаю что-то более продвинутое.

Заключение

Постарался подробно рассказать о структуре проекта и как я к этому пришел, очень много я не добавил, если пост зайдет, то я обязательно более подробно пройдусь по некоторым моментам: как я настраивал Matrix и на каком моменте я решил его убрать, как собирал локальный amnezia контейнер-клиент, что нового я добавил в релизе 1.4.0 и другое.

Также я перешел с manage_deploy.sh на отдельный GUI клиент, который будет полностью автоматизировать процесс подготовки к deploy. (написан на Go Wails). Про это тоже возможно сделаю статью.

Вся кодовая база проекта, подробная документация, инструкции по развертыванию открыты и доступны для сообщества:

🔗 GitHub-репозиторий: https://github.com/canntstand/ServeHub-2

Это моя первая статья на этом сайте и в то же время первый личный проект, которому я отдал так много времени (3 месяца). Буду рад вашему фидбеку в комментариях!

Потом проект вырос, в команду пришли ещё люди, и стало понятно: этот красивый монолит пора разделять.

Это было взвешенное решение. В какой-то момент общий фреймворк превратился в поле мерж-конфликтов, где ты уже не тесты пишешь, а разбираешься, кто чей page object сломал и почему Android отвалился после правки для iOS.

Appium тут ни при чём, как и скорость тестов. Проблема была в архитектуре: один общий слой для двух разных платформ начал мешать сильнее, чем помогать.

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

Ты сюда страдать пришёл или тесты писать?

После этого решение разделить Android и iOS на два проекта стало очевидным.

Сейчас у меня два отдельных проекта: mb-android-tests и mb-ios-tests. И знаете что? Это лучшее архитектурное решение за всё время на этом проекте. Серьёзно.

Контекст: что за проект и почему это важно

Финтех. Нативное приложение. Отдельные кодовые базы, Kotlin на Android, Swift на iOS. И UI там не «три кнопки и список», формы с десятками полей, кастомные контролы, WebView-вставки, платежи, валютные операции, бюджетные переводы. Ну вы поняли.

Стек: Java 21, TestNG, Appium 2.x, Selenide, Allure, Maven. CI на GitLab, крутится на Mac Mini. 5 Android-эмуляторов, 4 iOS-симулятора, 9 Appium-серверов — по одному на устройство.

Но это сейчас. А начиналось всё с одного жирного монолита.

Старый проект: 8 модулей и конструктор-монстр

Идея была «как в книжке»: один репозиторий, модульная структура, переиспользование. DRY во все поля. Ну а чё, красиво же.

8 модулей. Один mvn clean install. Все зависят от mobile-automation-framework, в котором живут DriverFactory, BaseTest, общие Page Objects и слой Steps.

А DriverFactory принимал 11 параметров. Одиннадцать, Карл.

Половина нужна только Android, другая только iOS. Но метод один. Потому что так более по программистцки, как написано в каждой второй статье про архитектуру автотестов.

Когда я работал один, было норм. Ты сам знаешь, от куда что идет.

А потом пришли люди.

Почему с людьми всё навернулось

Мерж-конфликты каждый божий день

Вот конкретная ситуация. Один человек правит LoginPage в общем фреймворке, добавляет метод для iOS, меняет локатор. Второй в тот же момент рефакторит этот же LoginPage под новую версию Android-приложения.

Мерж. Конфликт.

И тут начинается самое весёлое: какой локатор правильный? Для Android? Для iOS? Для обоих? Кто будет разбираться? Тот, кто мёрджит? А он вообще контекст понимает?

Это не единичный случай. Это было каждый день. Потому что mobile-automation-framework получился общим модулем, от которого зависят все. И все туда лезут. Постоянно.

Обновление одной библиотеки = блокировка всех

Решил обновить java-client с 7.x на 8.x. Нормальное желание — API поменялся, MobileElement удалили, capabilities переехали на типизированные Options.

Вот что произошло в реальности:

1. Меняю версию в parent pom.xml
2. MobileElement удалён → compilation error в DriverFactory, во всех DriverManager’ах
3. DesiredCapabilities → UiAutomator2Options / XCUITestOptions → переписываю все менеджеры
4. selenide-appium 1.x несовместим с java-client 8.x → обновляю до 2.x
5. selenide-appium 2.x требует Selenide 6.x → обновляю Selenide
6. Selenide 6.x ломает API page objects → переписываю page objects во всех модулях
7. А Selenide 6.x ещё и Java 8 не поддерживает → обновляю Java

Одна библиотека.

Задача «обновить одну библиотеку» превратилась в 50+ файлов, 4-5 каскадных обновлений, 2-3 недели работы. И всё это время develop нестабилен. Все заблокированы. Тесты не запускаются.

Две недели.

Из-за одной строчки в pom.xml.

Page Objects с if/else — это два page object в одном файле

Общие Page Objects звучат красиво на бумаге: пишем один раз, используем для обеих платформ. А на практике…

Это не page object. Это два page objects, запиханных в один файл через if/else. И так в каждом методе.

А сверху ещё слой Steps. Обёртки над page objects «для читаемости». И в steps тоже if (platform), потому что логика взаимодействия разная. На Android ты скроллишь через UiScrollable семантически, «прокрути до элемента с текстом X». На iOS координатами, «двигай палец из точки A в точку B». Один метод в steps, а внутри два разных мира.

В какой-то момент ловишь себя на мысли: я же не тесты пишу. Я подгоняю pages и steps под две платформы, чтобы фреймворк не развалился. Это уже не автоматизация тестирования, это поддержка фреймворка ради поддержки фреймворка.

Каждый работает в своём темпе и все друг другу мешают

У одного задача покрыть тестами новый экран на Android. У второго пофиксить падающие тесты на iOS. У третьего добавить тестовые данные.

Все трое лезут в mobile-automation-framework. Все трое меняют pom.xml, BaseTest, page objects. Каждый в своей ветке.

А потом мёрдж.

Технические причины, которые добили окончательно

Ладно, человеческий фактор. Но были и чисто технические штуки, которые окончательно убедили меня, что кроссплатформа тут бессмысленна.

Локаторы: работай с тем, что дают

Сразу скажу то, о чём мало кто пишет в статьях: в мобильной автоматизации ты работаешь с тем, что дают, а не с тем, что хотелось бы.

В теории есть AccessibilityID единый локатор для обеих платформ. Звучит хорошо. А на практике? Попробуй попросить мобильных разработчиков расставить одинаковые accessibility-идентификаторы на сотнях экранов. На Kotlin и Swift. Одновременно. Они тебя вежливо пошлют, но скорее всего не вежливо. И будут правы, у них свои спринты, свои дедлайны, и твои автотесты в их приоритетах где-то между «поправить тень у кнопки» и «никогда».

Так что реальный выбор:

XPath - работает, но на iOS может быть тормозным. На Android через UiSelector быстро, нативно, надёжно. На iOS через NSPredicate тоже ок. А «универсальные» XPath типа //*[@text='Войти' or @label='Войти'] это путь к боли, потому что Page Source на двух платформах два совершенно разных XML-дерева.

Координаты - костыль? Да. Но иногда единственный вариант. Когда у тебя кастомный контрол без accessibility-свойств, а разработчик говорит «это декоративный элемент», ты либо тыкаешь по координатам, либо не тестируешь.

OpenCV - есть ещё вариант с распознаванием элементов по картинке. Для некоторых кейсов реально выручает. Но это отдельная тема на целую статью, может напишу потом.

Суть в том, что «напиши один локатор и работай на двух платформах» это миф. Page Source на Android это android.widget.Button с resource-id. На iOS XCUIElementTypeButton с name и label. Разные типы элементов, разные атрибуты, разная глубина вложенности. Разные миры.

StaleElementReferenceException — «подарок» от iOS

Android рендерит UI через Choreographer синхронно с VSYNC. Элемент появился → стабилен → кликаем.

iOS рендерит через CoreAnimation с неявными анимациями. Элемент есть в дереве, но ещё анимируется. Формально кликабелен, фактически хрен.

Стандартный WebDriverWait с elementToBeClickable это не ловит. Элемент «кликабелен» по мнению Appium wait завершается. А потом click() падает, потому что DOM изменился между вызовами.

На Android этой проблемы нет вообще. Тот же тест, тот же wait, тот же код зелёный на Android, красный на iOS. Один и тот же метод, два разных результата. И это не баг это фундаментальное различие платформ.

Кастомные wait-стратегии для iOS отличаются от Android принципиально. Пихать их в один фреймворк строить leaky abstraction, которая протекает на каждом шаге.

Жесты — два разных мира

Свайп вниз на Android:

Свайп вниз на iOS:

Чувствуете разницу? И даже длительность свайпа важна: на Android 200мс это нормальный скролл. На iOS 200мс это fling, и элемент улетает за экран.

«Кроссплатформенная» обёртка для скролла функция на 40 строк с двумя ветками if (platform), внутри каждой и ещё if для performSwipeDown() vs performSwipeUp(). На 50+ экранах таких обёрток, которых десятки.

И каждая место для бага.

Решение: разделяй и властвуй

Решение было болезненным. Я реально откладывал, потому что казалось, что это шаг назад. Дублирование кода, нарушение DRY, всё такое. Мозг сопротивлялся.

А потом я просто сел и разделил.

Никаких общих page objects. Никаких общих steps. Никакого общего DriverFactory с 11 параметрами. Каждый проект со своим pom.xml, свои зависимости, свой BaseTest, свои локаторы.

Что осталось общего: подход к структуре (Maven + TestNG + Allure), CI-шаблоны, принципы организации. Но не код. Код полностью раздельный.

Что поменялось на практике

В Android-проекте DriverManager типизирован под AndroidDriver. В iOS под IOSDriver. Не AppiumDriver<MobileElement> с кастами и проверками, а конкретный тип для конкретной платформы. IDE подсказывает только релевантные методы. Компилятор ловит ошибки на этапе сборки, а не в рантайме.

BaseTest принимает ровно те параметры, которые нужны. Android: deviceName, platformVersion, udid, appPackage, appActivity, systemPort, serverUrl, appPath — 8 штук, все релевантные. iOS: deviceName, platformVersion, udid, appPath, serverUrl, wdaLocalPort — 6. Никаких @Optional("systemPort") со строкой “systemPort” в качестве дефолта.

А мерж-конфликты?

Когда один человек работает в mb-android-tests, а второй в mb-ios-tests то они вообще не пересекаются. Разные репозитории. Конфликт невозможен физически.

Обновление java-client в Android-проекте не затрагивает iOS. Хочешь обновить, обновляй. iOS продолжает работать на старой версии.

Добавить новый параметр для iOS? Меняешь BaseTest и testng.xml в iOS-проекте. Android даже не узнает.

Это прям кайф.

А как же дублирование кода?!

Конечно, конечно. Первый вопрос, который задают: «Но ведь ты пишешь тесты дважды!»

Нет.

Я пишу каждый тест один раз и без костылей. Без if (platform) в каждом методе. Да, для одного и того же экрана есть два теста, один для Android, один для iOS. Но каждый из них чистый, понятный, заточенный под свою платформу.

В старом варианте я тоже «писал один раз», а потом тратил столько же времени на поддержку if/else, мерж-конфликты и каскадные обновления. «Экономия» на создании оборачивалась переплатой на поддержке. С процентами.

Когда кроссплатформа всё-таки ок

Я не топлю за то, что кроссплатформенный фреймворк абсолютное зло. Есть ситуации, где он работает:

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

UI реально идентичен на обеих платформах. Бывает, наверное.

Команда из одиного человека. Сам пишешь, сам мёрджишь, сам разруливаешь. Голова справляется.

Минимум жестов. Нет сложных свайпов, drag-and-drop, pinch-to-zoom.

Если у тебя финтех, банк, enterprise-приложение с сотнями экранов, кастомными контролами и тремя+ QA, то два проекта дешевле. Не в строках кода, а во времени. В нервах. В часах, потраченных на мерж-конфликты вместо написания тестов.

Итого

Два проекта это не шаг назад и не двойная работа. Со стороны может выглядеть именно так, но на практике ты пишешь каждый тест один раз, под конкретную платформу, без лишних компромиссов. Потом поддерживаешь его без постоянных мерж конфликтов, каскадных обновлений и if/else в каждом втором методе.

Кроссплатформенный фреймворк на Appium для сложного нативного приложения часто оказывается иллюзией экономии.

В следующей статье покажу, как у нас устроена инфраструктура для 9 параллельных устройств на одном Mac Mini: порты, bash скрипты, Appium серверы и workaround’ы, которых нет в документации. Спойлер: там тоже всё не совсем как в гайдах.

Игнорирование в Git — это не магия, а просто набор шаблонов. Когда вы запускаете git status, Git сверяет имена файлов с тремя списками и решает, показывать их или нет. Важно: игнорируемый файл всё ещё лежит в рабочей директории, просто Git не предлагает его добавить в индекс.

• .gitignore — правила для всего репозитория, версионируются и делятся с командой.
• .git/info/exclude — локальные правила одного клона, не попадают в коммиты.
• ~/.config/git/ignore — глобальные правила для всех репозиториев на машине.
• git check-ignore -v filename покажет, какой именно файл игнорирует файл.
• Правильный выбор уровня избавляет команду от конфликтов и лишних правок .gitignore.

Три файла, которые говорят Git «не замечай»

Каждый из трёх файлов отвечает за свой масштаб. Отличаются они не синтаксисом — он везде одинаковый, — а областью действия и тем, попадают ли изменения в историю репозитория.

.gitignore — общие правила репозитория

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

Плюс очевиден: все члены команды видят одни и те же правила. Минус тоже очевиден: если правило нужно только вам, каждый раз править общий .gitignore и создавать коммит — избыточно.

.git/info/exclude — личные правила для одного репозитория

Внутри каталога .git каждого клона есть файл info/exclude. Он устроен так же, как .gitignore, но не входит в коммиты. Это идеальное место для файлов, которые есть только у вас: черновики, личные заметки, экспериментальные скрипты, локальные дампы.

Сценарий простой: вы держите в репозитории файл notes.txt с личными пометками. Добавлять его в .gitignore не хочется — коллегам он не нужен, а в .git/info/exclude он исчезает из git status только на вашей машине.

~/.config/git/ignore — глобальные правила для всей машины

Третий уровень действует на все репозитории текущего пользователя. Если у вас macOS, вы наверняка устали видеть .DS_Store в выводе git status. Вместо того чтобы добавлять его в каждый .gitignore, проще вынести на глобальный уровень.

Путь к глобальному файлу можно переопределить. Например, чтобы использовать .gitignore_global в домашней директории, выполните:

Вернуть значение по умолчанию можно командой git config --global --unset core.excludesFile.

Как проверить, кто именно игнорирует файл

Когда правил много, легко забыть, какой файл за что отвечает. Git предоставляет команду git check-ignore -v, которая показывает источник игнорирования: название файла с правилами, номер строки и сам шаблон.

Если файл игнорируется .gitignore, вывод будет начинаться с .gitignore; если локальным exclude — путь к нему; если глобальным ignore — путь в домашней директории. Если команда ничего не выводит, значит файл никто не игнорирует.

Полезно:
git check-ignore работает и с каталогами. Передайте путь к папке, чтобы узнать, почему она не попадает в индекс.

Когда какой уровень использовать

• .gitignore — правила, общие для всей команды: зависимости, сборочные артефакты, секреты.
• .git/info/exclude — персональные файлы внутри одного репозитория, которые не должны светиться в коммитах.
• ~/.config/git/ignore — файлы ОС и редактора, которые мешают в любом проекте на вашей машине.

Главный принцип: чем шире правило, тем реже его стоит менять. Глобальный ignore настраивается один раз при настройке рабочей машины, а .gitignore живёт вместе с проектом и развивается вместе с ним.

Выводы

Git предлагает не один, а три уровня игнорирования, и каждый решает свою задачу. .gitignore отвечает за командные договорённости, .git/info/exclude — за личный порядок в одном репозитории, а ~/.config/git/ignore — за чистоту рабочей машины в целом. Разделение уровней помогает не засорять общие правила личными исключениями и не тащить в коммиты то, что нужно только вам.

Хороший .gitignore защищает команду, а правильное использование exclude и global ignore защищает ваше собственное ментальное здоровье при работе с кодом.

Источник: Nelson Ameyin, «.gitignore isn’t the only way to ignore files in Git».

Попробуйте проверить свои репозитории: запустите git check-ignore -v на паре подозрительных файлов — возможно, вы найдёте правила, про которые давно забыли.

Godot Engine — это открытый кроссплатформенный игровой движок, который многие инди-разработчики рассматривают как альтернативу Unity. Проектом управляет некоммерческая Godot Foundation, а код собирается из пул-реквестов со всего мира. Это делает правила contributions ключевым инструментом выживания экосистемы.

Основной тезис обновления: любой существенный код должен быть написан человеком, который способен отвечать за него. Автономные ИИ-агенты, «vibe-coded» PR и ИИ-сгенерированный текст в обсуждениях попадают под запрет. Мелкие вспомогательные задачи — code completion, регулярки, find-and-replace — остаются, но с обязательным раскрытиием.

• Godot Foundation запретила ИИ-агентам и «vibe coding» создавать пул-реквесты с существенным кодом.
• Разрешены только мелкие вспомогательные операции: code completion, regex, find-and-replace с обязательным дисклеймером.
• Новички (≤3 принятых PR) теперь должны получать одобрение мейнтейнеров перед новыми фичами и крупными рефакторингами.
• Главный аргумент — ревью кода — это не только проверка, но и менторство будущих мейнтейнеров, а ИИ из этого контура выпадает.
• Похожие ограничения уже ввели Zig, Ghostty и curl: проблема AI slop стала системной для open source.

Что именно запрещено

В официальном посте Changes to our Contribution Policies Foundation перечисляет три запрещённые категории. Важно, что они касаются не только ботов, но и людей, которые копируют ИИ-вывод в PR, даже если потом вручную проверяют и дисклейсят.

• Автономные ИИ-агенты и «vibe coding». PR, созданные без глубокого участия человека, уже отклоняются автоматически.
• ИИ как автор существенного кода. Блоки логики, сгенерированные моделью, не принимаются независимо от того, кто нажал «Submit».
• ИИ-сгенерированный текст в коммуникации. Обсуждения с мейнтейнерами должны вестись людьми; исключение — машинный перевод человеческого текста.

Одновременно Foundation добавила барьер для новых участников: до трёх принятых PR — и вы не можете предлагать новые фичи или большие рефакторинги без явного разрешения. Цель не оскорбить новичков, а заставить их сначала разобраться в кодовой базе и завоевать доверие через багфиксы и документацию.

Почему это больше, чем «слишком много PR»

Сама по себе нагрузка на ревьюеров — старая open-source-боль. Но здесь добавляется другой эффект: обратная связь на ИИ-код не учит никого. Если модель сгенерировала патч, комментарий мейнтейнера не улучшит следующий выход той же модели, а автор-человек часто не понимает кода достаточно, чтобы довести правку до ума.

Reviewing PRs is already tedious work, but it is rewarding because reviewers generally feel that their efforts are contributing to educating a new contributor — who may become a future maintainer/reviewer. If your feedback on PRs is just being absorbed by a machine and not going towards mentoring a potential future maintainer, it becomes much harder to justify spending your free time on PR review.

В интервью Game Developer Foundation прямо говорит: «AI cannot take responsibility, and we can’t trust heavy users of AI to understand their code enough to fix it». Это не ненависть к ИИ как технологии, а признание, что ответственность за код должен нести конкретный человек.

«Contributor poker»: инвестиция в человека, а не в код

Эта логика не нова. В апреле 2026 года язык программирования Zig ввёл схожий zero-tolerance policy для ИИ-помощи в contributions. Вице-президент Zig Software Foundation Лорис Кро назвал ревью «contributor poker»: в покере вы играете против человека, а не против карт. Аналогично мейнтейнер вкладывает время не в конкретный PR, а в человека, который его прислал.

In contributor poker, you bet on the contributor, not on the contents of their first PR.

Когда PR написан ИИ, ставка срывается: ревью не превращает автора в будущего мейнтейнера, потому что автор не учится. Именно поэтому Godot и Zig формулируют запрет не как «ИИ плох», а как «менторская петля разрывается».

Godot не один: Zig, Ghostty и curl

Та же проблема AI slop в разных проявлениях встречается и в других крупных проектах. Терминал Ghostty ограничил поток ИИ-сгенерированных issue, а библиотека curl пережила настоящий DDoS фальшивыми security-репортами.

curl — самый известный пример. Создатель проекта Даниэль Стенберг писал, что в 2025 году доля валидных security-репортов упала примерно до одной из двадцати: «We are effectively being DDoSed». Часть отчётов содержала GDB-сессии и дампы регистров для функций, которых в curl не существует. В ответ команда закрыла bug bounty на HackerOne и перешла к более жёсткой модерации.

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

Пайплайн талантов под угрозой

Godot и Zig формулируют свой запрет в терминах mentorship pipeline — цепочки, по которой первый контрибьютор превращается в ревьюера, а ревьюер — в мейнтейнера. Если между «новичок» и «опытный разработчик» встает ИИ, обратная связь не доходит до человека, и вся цепочка останавливается.

В корпоративной среде эта же проблема звучит иначе: The New Stack в апреле цитировал Марка Руссиновича и Скотта Хансельмана из Microsoft, которые предупреждали: если компании будут заменять junior-разработчиков senior-инженерами с ИИ-ассистентами, «the profession’s talent pipeline collapses».

We need to take steps to reduce the burden on maintainers while ensuring we still have a pipeline to mentor new contributors to become future maintainers.

Что делать разработчикам

Запрет Godot не означает, что ИИ-инструменты нужно выбросить. Он устанавливает границу: модель может помогать в мелочах, но не может быть автором кода, за который ты не готов отвечать.

1. Читайте правила contributions конкретного проекта перед отправкой PR.
2. Раскрывайте использование ИИ для autocomplete, regex и мелких правок — честность ускоряет ревью.
3. Не отправляйте сгенерированные моделью блоки логики как «свой» код: вы должны понимать каждую строку.
4. Если у вас ≤3 принятых PR в Godot, начинайте с багфиксов и документации, а не с новых фич.
5. Проверяйте ИИ-репорты безопасности вручную: hallucinated уязвимости тратят время мейнтейнеров зря.

FAQ

Выводы

Godot не объявляет войну искусственному интеллекту. Она объявляет войну безответственному использованию ИИ в том месте open source, где важнее всего доверие и обучение. Движок остаётся открытым, но правила contributions становятся жёстче — и это, скорее всего, не последний подобный шаг в индустрии.

Things change every day with respect to the current suite of AI tools available. We will continue taking a conservative approach in our policies towards them, but we will re-evaluate as things evolve.

Источники: The New Stack, Godot Foundation, Game Developer.

С практической точки зрения проект на**й не нужен. Есть GitHub, GitLab и куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Почему не JSON

На старте я думал: «Положу всё в JSON, на кой мне база данных?» Проектов мало, пользователей немного, файлы текстовые — чего заморачиваться?

Подергал JSON туда-сюда пару дней и понял: не варик.

1. Конкурентный доступ. Два юзера одновременно коммитят — один перезаписывает файл другого.
2. Целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии.
3. Версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Вывод: JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор SQLite и схема БД

Выбрал SQLite, потому что:

• Не надо поднимать отдельный сервер
• Целостность данных на уровне движка (транзакции, foreign keys, rollback)
• Всё в одном файле — скопировал и унёс

Сущности:

• users — telegram_id, username, current_project_id
• projects — owner_id, name, thread_id (каждый проект живёт в своём треде канала)
• files — filename, current_version, флаг modified (файл изменился и готов к коммиту)
• file_versions — мясо. Каждая версия файла с полным содержимым. Привязана к file_id и опционально к commit_id
• commits — сообщение, время, ссылка на проект
• commit_files — связка коммитов с версиями файлов (many-to-many, чтобы поддержать ветки)

Почему так: я хотел иметь возможность откатиться к любой версии любого файла. Да, база распухнет, но текстовые файлы — это не гигабайты видео. Плюс наличие file_versions и commit_files позволяет делать diff между версиями и смотреть историю изменений.

В коде вместо голых кортежей из SQL — датаклассы:

Маркдауновый ад

Казалось бы: взял код, обернул в тройные апострофы, кинул в Telegram. Telegram сам подсветит синтаксис, если указать язык. Красота. В теории.

На практике Telegram использует свой диалект Markdown, где куча служебных символов: _ * [ ] ( ) ~ > # + - = | { } . !

Попытка 1: заэкранировать всё подряд. Результат: код превращается в кашу. Вместо def __init__- получается def |_|_init|_|_ — уже не запустишь, и в канале выглядит как говно.

Попытка 2: не экранировать вообще. Telegram шлёт на**й с ошибкой «can't parse entities».

Попытка 3: экранировать только то, что реально ломает разметку. Выяснилось, что порядок важен. Сначала экранируем точки и подчеркивания, потом обратную косую черту. Но и это не панацея — последовательности типа \*

после экранирования превращаются в \\*, и Telegram снова недоволен.

Попытка 4: разбивать на части. Для больших файлов делаю превью (первые 50 строк), экранирую их, отправляю как код, а полную версию — файлом. И тут начался ад: Telegram находил ошибки в тех частях кода, которых в превью вообще не было. Оказывается, он всё равно парсил полный код, даже если отправлялась только его часть.

Попытка 5 (финал): забил на Markdown и перешёл на HTML. Telegram умеет его принимать. Да, он не такой красивый, но зато предсказуемый:

Никаких точек, подчеркиваний, обратных слешей. Просто экранируем три символа — и код летит как надо.

Security by design

Когда бот начал обрастать функциями, я задумался о безопасности. Чтобы никто не мог коммитить или удалять чужие файлы, начал писать проверки в каждую команду:

Добавил в /commit. Потом решил с другого аккаунта потестировать команды на чужих файлах. И тут бот на каждую команду стал выдавать «файл не найден» или «проект не найден». И я понял: безопасность уже работает. С самого начала. Из коробки. Без единой строчки кода.

Как так вышло? В таблице projects с самого начала было поле owner_id. При создании проекта я писал туда telegram_id владельца. Все запросы к БД фильтруются по этому полю:

Показать проекты — только свои. Найти файл — только в своих проектах. Выбрать проект — только из своих. Никаких лишних проверок. Просто SQL-запросы, которые с самого начала учитывали владельца.

Команды: от семи до двух десятков

Изначально казалось, что команд будет немного. Но...

Жизнь рассудила иначе.

• База: /start, /init, /use, /list, /ls, /commit, /log, /status
• Удаление: /rm, /rmproject + подтверждение
• Игнор: /ignore, /ignored, /unignore
• Ветки: /branch, /branches, /checkout
• Диффы и просмотр: /diff, /cat

Итого — уже под два десятка. И это не предел.

Простота > абстракции

В моём коде нет абстрактных базовых классов. Совсем. Потому что они нужны только когда у тебя есть минимум две разные реализации одного и того же. В GitGram всё проще: один способ работать с БД, один способ шифровать, один способ парсить .gitignore.

Если завтра появится вторая реализация — тогда и буду делать интерфейс. А пока это просто оверхед.

В GitGram:

• Хочешь понять, как работает add_file — идёшь в database.py и читаешь 10 строк кода.
• Хочешь увидеть обработчик /commit — открываешь bot.py и смотришь.

Никаких AbstractMinerShieldEventProcessor, BaseGitGramManager, InterfaceProviderFactory.

Код должен быть тупым. Чем тупее — тем проще его читать и отлаживать.

Что дальше

В планах:

• Докрутить коллаборацию (несколько человек над одним проектом)
• Приватные репозитории
• Кодспейс прямо в боте (да да знаю я сошёл с ума и бла бла бла..)

Итог

GitGram принимает файлы, режет их на куски если надо, постит в канал с подсветкой. Коммиты ходят, ветки переключаются, диффы показываются. Всё это в тредах, каждый проект отдельно.

На практике GitGram ни к чему. Но сама задумка — Git в Telegram — это же так прикольно. Просто посмотреть, можно ли такое вообще запилить.

Если хочешь поучаствовать

• GitGram
• Чат для хардкорных: @sandbox_hardcore — вся сырая разработка, факапы и обсуждения (без цензуры)

Подписывайся на мой TГ-канал — там я публикую все свои эксперименты, код и приглашаю к обсуждению. Только факты, мат и никакой политоты.

SafeLine WAF — это бесплатный инструмент, который я лично тестировал.

Это полностью open-source решения, продукт с действительно бесплатной Community Edition, где ключевые функции не урезаны.

SafeLine WAF — веб-приложенийный межсетевой экран, который действительно поставляется с разумными настройками по умолчанию

Что он делает:

Защищает веб-приложения от SQL-инъекций, XSS-атак, командных инъекций, CSRF, SSRF, атак включения файлов и других угроз из списка OWASP Top 10. Также поддерживает защиту от CC/DDoS-атак, управление ботами и может работать как шлюз аутентификации.

Почему он:

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

SafeLine использует другой подход — вместо того чтобы полностью полагаться на сигнатурное обнаружение, он применяет движок семантического анализа, который фактически анализирует и понимает входящие HTTP-запросы. Это позволяет добиться более высокого уровня обнаружения при значительно меньшем количестве ложных срабатываний по умолчанию.

Некоторые показатели, которые стоит учитыват

1. Уровень обнаружения - SafeLine (Balanced) (71.65%), ModSecurity (Level 1) (69.74%), Cloudflare (Free) (10.7%)
2. Уровень ложных срабатываний - SafeLine (Balanced) (0.07%), ModSecurity (Level 1) (17.58%), Cloudflare (Free) (0.07%)
3. Точность - SafeLine (Balanced) (99.45%), ModSecurity (Level 1) (82.20%), Cloudflare (Free) (98.40%)

Сбалансированный профиль SafeLine обнаруживает более 70% атак, при этом блокируя легитимный трафик ошибочно всего в 0.07% случаев. Это именно тот уровень настроек по умолчанию, который можно использовать в промышленной среде без постоянного ручного контроля.

Установка выполняется одной командой

После запуска он разворачивается как набор Docker-контейнеров: Tengine (форк Nginx) используется в качестве reverse proxy, отдельный сервис отвечает за семантический анализ, PostgreSQL хранит конфигурации и логи, а удобная веб-панель администратора работает на порту 9443.Community Edition поддерживает до 10 сайтов, чего достаточно для большинства личных проектов и небольших бизнес-сценариев.

Сайт: https://cyberserval.tech/landing/safeline

GitHub: github.com/chaitin/SafeLine (более 21 тыс. звёзд)

Лицензия: GPL-3.0 / MIT (Community Edition)

Но при этом к такому коду часто боятся прикасаться. И не без причины. В старых системах редко бывает понятная карта зависимостей. Документация устарела, часть знаний живет только в головах нескольких разработчиков, а бизнес при этом продолжает ждать новых релизов, интеграций и продуктовых экспериментов.

Так появляется классическая ловушка legacy: систему надо модернизировать, но остановить развитие нельзя. Переписать всё с нуля страшно, поддерживать как есть — всё дороже. В результате продукт обрастает временными решениями, скорость разработки падает, а стоимость каждого следующего изменения растет.

Хорошая новость в том, что модернизация legacy-кода не обязана быть большим взрывом. Старую систему можно менять постепенно, сохраняя рабочий продукт, не замораживая фичи и не устраивая один критический релиз, от которого зависит всё.

Почему Big Bang-переписывание чаще всего заканчивается плохо

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

На старте такой план часто звучит логично. Особенно если текущая система действительно мешает развитию. Например, мобильное приложение растет, у него уже миллионы пользователей, бэкенд написан несколько лет назад как монолит, а каждая новая фича требует изменений в десятке мест. Команда устала чинить регрессии, бизнес устал ждать, и всем хочется «один раз нормально переписать».

Проблема не в самой идее переписывания, а в условиях, при которых оно проваливается. Большой риск возникает, когда совпадают четыре фактора: переписывание занимает много месяцев, в это время бизнес продолжает развивать старую систему, новая версия покрывает сразу большую часть функциональности, а откат связан с миграцией данных. Если все четыре пункта присутствуют, Big Bang почти гарантированно превратится в долгий и дорогой проект.

Допустим, команда решила переписать модуль заказов в e-commerce-продукте. В старой версии есть корзина, промокоды, доставка и оплата. Команда планирует за полгода сделать новый сервис заказов. Но за эти полгода бизнес добавляет подписки, подарочные сертификаты, частичную оплату бонусами и новую логику возвратов. В итоге новая система, которую проектировали под старые требования, к моменту релиза уже нуждается в доработке.

Есть и другая проблема: большой релиз почти всегда несет максимальный риск. Если вы заменяете крупный кусок системы целиком, ошибка влияет сразу на большую часть пользователей. Откат тоже становится сложным, потому что новая логика уже связана с новыми данными, контрактами и интеграциями.

Big Bang всё-таки бывает оправдан — но в узких условиях. Если кодовая база молодая (год-два), пользователей мало, у системы нет критичного состояния в БД и продукт можно временно заморозить или вести в обоих контурах параллельно, полное переписывание может оказаться дешевле постепенной миграции. Это редкая ситуация, и она быстро исчезает по мере роста продукта. В зрелых системах безопаснее работает другой подход — постепенная архитектурная эволюция.

Пример: как команда переписала сервис документов и потеряла полгода

Команда сопровождала сервис — старый модуль на aiohttp с Pydantic v1, через который проходила вся обработка путевых листов и актов осмотра транспорта. Сервис существовал шесть лет, был покрыт тестами фрагментарно, а его API использовали мобильное приложение водителей, диспетчерская веб-панель и пакетный импорт.

Команда решила переписать сервис целиком: перейти на FastAPI, обновить Pydantic до v2, заодно почистить контракты и заменить внутреннее хранилище документов с MongoDB на PostgreSQL. План был рассчитан на четыре месяца.

Через восемь месяцев проект всё ещё не был готов к выкатке, а к десятому месяцу команда откатила миграцию полностью. Причин было несколько.

Во-первых, переписывание шло параллельно с продуктовой разработкой. За время миграции бизнес добавил два новых типа документов и изменил правила подписи актов. Новая система проектировалась под старые требования и к моменту готовности уже не соответствовала продукту.

Во-вторых, команда не написала характеристических тестов. Поведение «как есть» нигде не было зафиксировано, и расхождения находились только в продакшене после переключения.

В-третьих, у старого сервиса были скрытые побочные эффекты, о которых никто не помнил. При смене статуса документа публиковал событие в Kafka, которое читал биллинг и сервис аналитики. В новой реализации это поведение не было воспроизведено, потому что в коде оно выглядело как «лишний» вызов. После переключения биллинг перестал получать события, и расхождение обнаружили только через две недели — по жалобе финансового отдела.

В-четвёртых, переключение было сделано «в лоб»: маршрут в API Gateway просто перенаправили на новый сервис. Фича-флага не было, теневого запуска не было, плана отката не было. Когда выяснилось, что новый сервис строже валидирует исторические форматы документов и отклоняет часть старых записей, быстро вернуться на старую реализацию не получилось — её к тому моменту уже отключили на стенде, а в БД успели уйти записи в новом формате.

В итоге миграцию свернули, потратив около десяти человеко-месяцев и потеряв доверие бизнеса. Сервис до сих пор работает в исходной реализации, а команда переходит к плану, описанному ниже.

Strangler Fig Pattern: как заменить систему по частям

Один из самых практичных подходов к модернизации legacy-кода — Strangler Fig Pattern. В софтверном виде паттерн был сформулирован Мартином Фаулером в 2004 году под названием StranglerFigApplication. Идея проста: не переписывать систему целиком, а постепенно выносить отдельные части в новую реализацию.

Название пришло из биологии. Фикус-душитель растет вокруг дерева-хозяина и постепенно вытесняет его. В архитектуре принцип похожий: старая система продолжает работать, новая функциональность появляется рядом, а затем отдельные потоки постепенно переводятся на новую реализацию.

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

Сначала команда описывает текущий контракт: какие события приходят в модуль уведомлений, какие каналы используются, какие шаблоны отправляются, какие ошибки считаются допустимыми. Затем рядом создается новый сервис уведомлений, который реализует тот же контракт. На первом этапе он может даже не отправлять реальные сообщения, а только принимать события и логировать результат. После проверки часть трафика переводится на новую реализацию. Когда сервис стабилизируется, старый код уведомлений удаляется из монолита.

Strangler Fig хорошо работает там, где между старым и новым кодом есть сетевая граница: HTTP, message bus, RPC. Если такой границы нет — например, нужно постепенно заменить функцию или класс внутри одного процесса — используется родственный паттерн Branch by Abstraction: над старой реализацией создается абстракция, рядом пишется новая реализация, переключение происходит через конфигурацию или фича-флаг, после стабилизации старая ветка удаляется. Снаружи это выглядит как Strangler Fig, но без сетевого прокси.

Такой подход снижает риск. В системе нет одного большого релиза, где всё меняется сразу. Есть серия небольших контролируемых изменений. Каждое можно протестировать, измерить и откатить.

Главное правило: сначала повторить поведение, потом улучшать

Одна из частых ошибок при модернизации legacy-кода — попытка одновременно переписать систему и улучшить бизнес-логику. Команда смотрит на старый модуль и думает: «Раз уж мы его трогаем, давайте сразу сделаем нормальную архитектуру, изменим контракты, уберем странные кейсы и перепишем поведение».

Это опасный путь. В legacy-системах странное поведение часто существует не случайно. За ним может стоять неочевидное бизнес-правило, старый клиент, интеграция с внешней системой или исторический баг, на который уже кто-то завязался.

Например, в системе расчета налогов может быть правило: для контрактов, заключенных до 2018 года, НДС округляется в меньшую сторону до целого рубля, а для всех остальных — по математическим правилам. Новый разработчик может решить, что это ошибка, и «исправить» округление. Но потом выяснится, что часть крупных клиентов держит это поведение в своих сверках, а смена правила приведет к расхождениям в актах и претензиям.

Прежде чем менять поведение, его нужно зафиксировать. Для этого пишут характеристические тесты (characterization tests, иногда называемые golden master или approval tests). Идея простая: на реальных данных или их обезличенных копиях прогоняется старая реализация, её ответы сохраняются как эталон, и любые будущие изменения, отклоняющиеся от эталона, отлавливаются автоматически. Тесты пишутся не для красоты, а для того, чтобы зафиксировать существующее поведение — даже странное — перед тем, как его трогать. Подробно эта техника описана у Майкла Физерса в книге Working Effectively with Legacy Code; на практике её удобно реализовать через библиотеки семейства approval-tests (approvaltests-python, approvaltests-java и аналоги).

Поэтому первый этап модернизации — не улучшение, а воспроизведение текущего поведения. Новая реализация должна вести себя так же, как старая. Даже если старое поведение кажется странным. Только после стабилизации можно отдельно обсуждать, что именно стоит менять.

Feature toggles: как включать новую логику без риска

Feature toggles, или фича-флаги, — один из главных инструментов безопасной миграции. Они позволяют включать и выключать новую логику без деплоя.

В обычной разработке релиз часто выглядит бинарно: код либо выкатили, либо нет. При миграции legacy это неудобно. Гораздо безопаснее иметь возможность включить новую реализацию для 1% пользователей, затем для 10%, потом для половины аудитории и только после этого для всех.

Например, команда переносит расчет стоимости доставки из монолита в новый сервис. С помощью фича-флага это выглядит так:

user_id передается явно, чтобы решение «попал ли пользователь в новый сегмент» было стабильным от запроса к запросу. Иначе один и тот же клиент будет получать разные ответы при обновлении страницы, и поведение системы станет непредсказуемым.

На первом этапе флаг включают только для внутренней команды. Потом для тестового сегмента пользователей. Затем для небольшой доли реального трафика. Если метрики стабильны, долю увеличивают. Если появляются ошибки, флаг выключают, и пользователи снова идут в старую реализацию.

Важно различать два разных типа флагов. Флаг постепенной выкатки (rollout flag) меняется редко и контролирует, какой процент пользователей видит новую логику. Kill switch — отдельный флаг, единственная задача которого — мгновенно выключить новую реализацию при инциденте. Kill switch должен опрашиваться на каждом запросе, его кэширование должно жить секунды, а не минуты, и он принципиально не должен зависеть от той системы, которую он выключает. Иначе в момент аварии может оказаться, что выключатель сам недоступен.

В качестве инфраструктуры для флагов команды обычно берут одну из платформ: LaunchDarkly, Unleash, Flagsmith, GrowthBook, либо собирают собственную поверх Redis или конфигурационного сервиса. Для миграции важны три свойства: быстрое распространение изменений (секунды, а не минуты), поддержка таргетинга по пользователю/сегменту и аудит — кто и когда менял флаг.

Важно, что фича-флаг — это не просто if в коде. Для серьезной миграции нужны правила: кто может включать флаг, как быстро его можно отключить, какие метрики отслеживаются, когда флаг должен быть удален.

Последний пункт особенно важен. Если флаги не удалять, система быстро превращается в набор ветвлений, где никто уже не понимает, какая логика актуальна.

Shadow testing: как проверить новую систему на реальном трафике

Feature toggles помогают безопасно переключать пользователей. Но перед этим хорошо бы понять, совпадает ли новая логика со старой. Для этого используют shadow testing.

Shadow testing — это запуск новой реализации параллельно старой, но без влияния на пользователя. Пользовательский запрос по-прежнему обрабатывает старая система, а новая получает копию запроса и считает результат «в тени». Пользователю этот результат не показывается. Команда только сравнивает ответы.

Например, есть старый модуль расчета скидок. Он учитывает промокоды, сегмент пользователя, историю покупок, регион и партнерские условия. Команда пишет новый сервис скидок. Чтобы не переключать пользователей сразу, можно запустить теневой режим:

Два момента, на которые стоит обратить внимание в этом коде. Теневой вызов запускается через asyncio.create_task — корутина сразу планируется в event loop и начнёт выполняться, как только функция вернёт управление. И весь блок завернут в try/except: исключение в новой логике не должно ронять основной запрос. Без этих двух свойств shadow testing рискует ухудшить продакшен вместо того, чтобы безопасно его проверить.

Небольшая оговорка для продакшена: event loop держит на task только слабую ссылку, и без сохранённой ссылки задача может быть собрана сборщиком мусора прямо во время выполнения. В реальном коде Task имеет смысл класть в set фоновых задач и удалять оттуда через add_done_callback. В примере выше эта обвязка опущена для читаемости.

Для критичной доменной логики — платежей, биллинга, расчета тарифов — допустимый уровень расхождения должен быть около нуля: цель в shadow-режиме не «как можно меньше различий», а «понимаем каждое расхождение». Для менее чувствительных доменов (рекомендации, ранжирование результатов поиска) можно жить с расхождением в долях процента, но и там расхождения нужно классифицировать, а не игнорировать. Возможно, это баги новой реализации. А возможно, старая система содержит устаревшую логику, которую нужно отдельно обсудить с бизнесом.

Shadow testing особенно полезен для критичных доменных частей: платежей, биллинга, расчета тарифов, персональных предложений, транзакций. Там нельзя просто «попробовать на пользователях» и посмотреть, что будет.

При этом важно отличать теневую проверку чтения от теневой проверки записи. Чтение проверить относительно дёшево: запрос идёт в обе системы, ответы сравниваются, никаких внешних эффектов нет. С записью всё сложнее. Если новая реализация в shadow-режиме действительно создаст заказ, спишет деньги или отправит письмо, у пользователя возникнут двойные эффекты. Поэтому для writes либо вводят идемпотентные ключи и shadow-режим без реальных побочных действий (внешние вызовы заменены no-op-стабами, БД — отдельной shadow-копией), либо вообще отказываются от теневой проверки записи в пользу постепенной выкатки за фича-флагом.

Сравнение ответов в реальной системе тоже не сводится к одной функции compare. Нужно отдельно решать, как игнорировать «нормальный» шум (метки времени, идентификаторы, порядок коллекций), как сэмплировать трафик, чтобы не утопить хранилище расхождений, и как организовать триаж — кто и в каком ритме разбирает накопившиеся диффы. Готовые решения этого класса — GitHub Scientist (Ruby и его порты в другие языки), Twitter Diffy, либо собственный лёгкий регистратор поверх Kafka и таблицы расхождений.

С чего начинать модернизацию

Начинать лучше не с самого больного и не с самого центрального модуля. Это звучит контринтуитивно, потому что обычно хочется сразу взяться за главный источник проблем. Но если начать с ядра системы, команда быстро упрется в максимальное количество зависимостей и рисков.

Удобный способ выбрать первый кусок — оценить кандидатов по двум осям: насколько модуль критичен для бизнеса (low / high) и насколько сильно он связан с остальной системой (low / high). Начинать стоит с квадранта low-criticality + low-coupling: ошибки в нем не уронят бизнес-показатели, а малое количество зависимостей позволит провести миграцию полностью, не утянув за собой смежные модули. Высоко-критичные и сильно связанные части (платежи, ядро авторизации) трогают в последнюю очередь — на этот момент команда уже наберёт опыт безопасной миграции.

Хорошие точки входа обычно: уведомления, генерация отчетов, поиск, история операций, профиль пользователя, отдельная часть каталога. Важно, чтобы у команды была возможность описать контракт: какие данные входят, какие выходят, какие ошибки возможны, какие внешние системы участвуют.

Допустим, в банковском приложении есть старый модуль истории операций. Он медленный, сложно расширяется, но при этом не выполняет сами транзакции. Это хороший кандидат для первой миграции. Ошибка в истории операций неприятна, но обычно менее критична, чем ошибка в списании денег.

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

Миграция данных: самая сложная часть

Большая часть статьи говорит о маршрутизации запросов и переключении трафика. Но в реальных проектах основная сложность лежит ниже — в данных. Старая и новая реализации почти всегда работают с общим состоянием: одной БД, одним хранилищем документов, одним набором очередей. Переехать туда «одним коммитом» нельзя.

Базовый рабочий приём — Expand-Contract (он же Parallel Change). Изменение схемы делается в три такта. На этапе expand в БД добавляются новые поля, таблицы или индексы, при этом старое поведение полностью сохраняется. Затем — migrate: обе реализации начинают писать и в старое, и в новое место (dual writes), а отдельный фоновый процесс делает backfill — заполняет новые поля историческими данными. После этого читатели по одному переключаются на новую схему. Только когда никто из читателей не использует старую структуру, наступает contract — удаление лишних колонок и таблиц.

Несколько практических деталей, которые часто упускают:

· Dual writes — это не бесплатная операция. Две записи означают две точки отказа. Если одна из них упала, нужно решать, что делать: продолжать ли работу, ставить ли событие в очередь на повтор, помечать ли запись как несогласованную. Простое «сначала пишем туда, потом сюда» в продакшене на нагрузке приводит к расхождениям.

· Backfill часто длиннее, чем кажется. На большой таблице миграция в одном UPDATE блокирует продакшен. Поэтому backfill делают батчами по N тысяч строк с паузами, отслеживают прогресс и предусматривают возможность остановить и продолжить.

· Онлайн-изменения схемы на крупных таблицах делаются не штатным ALTER TABLE, а специализированными инструментами: gh-ost или pt-online-schema-change для MySQL, встроенные онлайн-механизмы PostgreSQL для индексов и колонок, Liquibase/Flyway — для управления версионированием изменений в репозитории.

· Shadow testing данные не покрывает. Можно сравнить, что новая реализация возвращает то же, что и старая, но если за этим стоит другая схема в БД, проверка корректности самой миграции данных — это отдельная работа: сверки, контрольные суммы, выборочный аудит исторических записей.

Без этих шагов любая красивая фасадная архитектура наталкивается на разъезжающиеся данные — и тогда даже идеальный Strangler Fig снаружи не спасает.

Прокси-слой как точка контроля

Чтобы постепенно заменять legacy-код, нужно управлять маршрутизацией запросов. Для этого часто создают прокси-слой, API Gateway или фасад, через который проходит обращение к старой и новой логике. В терминах Domain-Driven Design такой слой часто называют Anti-Corruption Layer: он защищает новую реализацию от старых контрактов и наоборот, позволяя двум моделям сосуществовать без взаимного «загрязнения».

Без такой точки контроля миграция становится хаотичной. Часть клиентов ходит напрямую в старый модуль, часть — в новый, часть использует обходные пути, а команда теряет возможность централизованно переключать трафик.

Прокси-слой решает несколько задач. Он скрывает детали реализации от клиентов, позволяет направлять часть запросов в новую систему, поддерживает фича-флаги, собирает метрики и упрощает откат.

В качестве технической основы команды обычно берут один из трех вариантов: классический API gateway (Kong, AWS API Gateway), service mesh (Envoy, Istio) или более простой reverse proxy (NGINX, HAProxy). Service mesh особенно удобен, когда трафик уже идёт внутри Kubernetes-кластера: маршрутизацию можно менять конфигурацией, без правок кода клиентов и сервисов.

Например, мобильное приложение обращается к endpoint /orders/history. Раньше этот endpoint напрямую обслуживал монолит. После введения API Gateway приложение продолжает ходить по тому же контракту, но внутри gateway может решать, куда направить запрос: в legacy-модуль или новый сервис истории заказов.

Управление маршрутизацией обычно делается не «всё или ничего», а на основании атрибутов запроса: значения заголовка (X-Migration-Cohort: new), куки, хэша от user-id (стабильное разбиение пользователей на сегменты) или географического региона. Это позволяет выкатывать новую реализацию сначала на одну страну, на сотрудников самой компании или на тестовый сегмент — и только потом расширять охват.

Для клиента ничего не меняется. Для команды появляется управляемость.

Наблюдаемость: без метрик миграция превращается в гадание

Постепенная модернизация невозможна без нормальной наблюдаемости. Если команда не видит, что происходит внутри системы, она не сможет безопасно переключать трафик.

Минимальный набор — это логи, метрики и распределенная трассировка (distributed tracing). Нужно понимать, сколько запросов идет в старую и новую реализацию, сколько ошибок возникает, как меняется latency, где появляются таймауты, какие статусы возвращаются, какие бизнес-метрики проседают.

Технические метрики стоит формулировать не как «средний ответ» и «процент ошибок», а в терминах SLI и SLO: целевые показатели вида «99.9% запросов на /orders/history отвечают быстрее 300 ms за 30 дней» с явным error budget. Latency измеряется по перцентилям (p50, p95, p99) — среднее значение почти всегда обманчиво, а хвосты распределения говорят о реальном опыте пользователя. На время миграции имеет смысл выставить отдельные SLO для нового и старого пути и сравнивать их.

В качестве инструментов де-факто стандартом стал OpenTelemetry для трассировок, метрик и логов — единый протокол, который пишет в практически любое хранилище. Дальше — Prometheus и Grafana для метрик, Jaeger или Tempo для traces, Sentry или аналог для ошибок. Для миграции важна возможность фильтровать метрики по «варианту» — отдельно по старому и новому пути — иначе все цифры смешаются и реальную динамику будет не видно.

Технических метрик недостаточно. Если команда переносит оформление заказа, важно смотреть не только на 500 ошибки и время ответа, но и на конверсию в оплату, количество брошенных корзин, повторы запросов, обращения в поддержку.

Пример: новая система формально отвечает быстрее старой и не дает ошибок. Но после включения на 10% пользователей падает конверсия в оплату. Причина может быть не в серверной ошибке, а в изменении порядка полей, другом тексте сообщения или потере какого-то edge-case. Без бизнес-метрик команда может решить, что миграция успешна, хотя для продукта она уже создает проблему.

Практическая последовательность миграции

Рабочая последовательность обычно выглядит так.

Сначала команда выбирает ограниченный участок системы. На этом этапе важно не просто назвать модуль, а описать его границы. Какие сценарии он закрывает? Кто его вызывает? Какие данные он читает и пишет? Какие внешние интеграции использует? Какие неочевидные бизнес-правила в нем есть?

Затем поверх legacy-логики создается стабильный контракт. Это может быть API, фасад, gateway или отдельный слой внутри приложения. Главная задача — сделать так, чтобы клиенты зависели не от внутренней реализации, а от понятного интерфейса. На этом этапе полезно вспомнить про contract testing (Pact, Spring Cloud Contract): автотесты со стороны потребителей фиксируют, что именно они ожидают от API, и предупреждают о ломающих изменениях до того, как они доедут до продакшена.

После этого рядом пишется новая реализация. Она должна повторять текущее поведение, а не сразу становиться «идеальной версией будущего». На этом этапе полезно фиксировать все расхождения: где старая система работает странно, где требования не описаны, где бизнес-правила требуют уточнения.

Следующий этап — shadow testing. Новая система получает копии реальных запросов, считает результат, но пользователю по-прежнему возвращается ответ legacy. Команда сравнивает результаты и устраняет расхождения.

Когда новая реализация достаточно стабильна, начинается постепенное переключение через feature toggles. Сначала внутренние пользователи, потом 1% реального трафика, затем 5–10%, затем 50% и только после этого 100%.

На каждом этапе команда смотрит на метрики. Если всё стабильно, движение продолжается. Если появляются проблемы, флаг выключается, трафик возвращается в legacy, а команда разбирает причины.

Последний этап — удаление старого кода. Это не формальность, а обязательная часть миграции. И «удалить старый код» — это не один коммит, а явный Definition of Done: вырезана старая ветка кода, удалён фича-флаг, обновлена документация и схемы архитектуры, переименованы или удалены устаревшие дашборды и алерты, обновлены runbook’и для on-call и проведено короткое внутреннее обучение. Если этого не сделать, через полгода никто уже не вспомнит, какой путь актуален, и легаси-ветвление останется в коде навсегда.

Откат миграций: дешёвый только пока не пошли записи

Откатить миграцию, в которой ещё не было записи в БД, легко: достаточно переключить фича-флаг, и трафик снова идёт через старую реализацию. Откатить миграцию, в которой новая система уже неделю писала данные в новые таблицы, — отдельный, гораздо более тяжёлый разговор.

Поэтому ещё на этапе проектирования каждое изменение должно сопровождаться явным планом отката. Удобно различать три типа шагов.

Полностью обратимые шаги. Чтение через новый сервис, расчёт «в тени», новые метрики. Откат — выключить флаг. Это самый комфортный режим, и в нём стоит держать миграцию как можно дольше.

Обратимые с компенсацией. Новая реализация пишет дополнительные данные (например, дублирует операции в новую таблицу), но старый источник тоже обновляется. Откат возможен, но требует решить, что делать с уже записанными данными: оставить, очистить, синхронизировать. План этих действий должен быть написан до выкатки, не во время инцидента.

Forward-only. После некоторой точки откат становится невозможен — например, после того, как старая схема удалена или внешние интеграции перенастроены на новый сервис. Такие шаги допустимы, но к ним нужно приходить отдельно, осознанно, с особенно строгими SLO в предыдущем этапе. До forward-only-перехода имеет смысл подержать систему в режиме параллельной работы дольше, чем по графику.

Базовое правило: ни один шаг миграции не должен уходить в продакшен, если у команды нет письменного ответа на вопрос «как мы откатываемся в случае проблемы». Иначе при инциденте откатываться будут на ходу — и не факт, что успешно.

Пример: как тот же сервис мигрировали со второй попытки

После неудачного опыта команда взялась за тот же сервис заново, но изменила подход.

На первом шаге они зафиксировали поведение существующего сервиса. На самые часто используемые сценарии (создание путевого листа, подпись акта осмотра, выгрузка пакета документов за период) написали характеристические тесты на реальных продакшен-данных, обезличенных и сохранённых как фикстуры. Любое будущее изменение поведения теперь падало в CI как явное расхождение.

Параллельно команда провела инвентаризацию побочных эффектов. Из исходного кода и логов выяснилось, что сервис не только хранит документы, но и: публикует событие в Kafka при смене статуса, инкрементирует счётчик в Redis для рейтинга водителей, отправляет webhook во внешнюю систему партнёра, пишет в таблицу аудита. Каждый из этих эффектов попал в отдельный пункт чек-листа «что должно остаться» в новой реализации.

Затем команда выбрала первый кусок для выноса — не весь сервис, а только чтение документов (GET /documents/{id} и GET /documents/by-driver/{driver_id}). Это была наименее рискованная часть: ошибки в чтении неприятны, но не ломают финансовые потоки.

Новый сервис написали на FastAPI рядом со старым. На уровне API Gateway появилось правило маршрутизации: запросы на чтение шли в старый сервис, но в фоне дублировались в новый. Ответ пользователю всегда возвращал legacy, а ответ нового сервиса сравнивался с эталоном и записывался в отдельную таблицу для разбора. Использовали обёртку поверх asyncio.create_task — на ответ пользователя теневой вызов не влиял.

За три недели shadow-режима команда нашла четыре расхождения. Два оказались багами новой реализации (округление времени, неправильная сортировка вложений). Два — давно забытыми особенностями старого сервиса (одно поле возвращалось в UTC, другое — в локальной зоне; так было исторически, бизнес не возражал, но в новой реализации захотели единый формат). Все четыре зафиксировали явно: баги — починили, особенности — согласовали с продуктовой командой как осознанное изменение.

Когда расхождений не осталось, включили фича-флаг на сотрудников самой компании. Через неделю — на 1% реальных водителей. Дальше шаг по 5%, 25%, 50%, 100% с паузой в несколько дней между этапами. На каждом шаге следили не только за HTTP-ошибками и latency, но и за продуктовыми метриками: количество подписанных актов, время от открытия документа до подписи, доля повторных запросов. Один раз пришлось откатиться с 25% на 5% — в одном из регионов выросло время отклика из-за неэффективного запроса. Исправили, выкатили снова.

Через два месяца чтение полностью перешло в новый сервис. Старый код чтения и фича-флаг удалили в том же релизе. После этого по той же схеме мигрировали запись документов, потом публикацию событий, потом импорт из внешних систем. Полная миграция заняла девять месяцев — почти столько же, сколько провалившийся Big Bang, — но продукт всё это время продолжал развиваться, инцидентов не было, и в конце команда осталась с системой, которую понимает.

Типичные ошибки при работе с legacy

Первая ошибка — пытаться улучшить всё сразу. Команда одновременно меняет архитектуру, бизнес-логику, контракты и инфраструктуру. В результате становится невозможно понять, какая именно часть вызвала проблему. Правильнее сначала воспроизвести поведение, стабилизировать новую реализацию и только потом улучшать.

Вторая ошибка — недооценивать скрытые зависимости и побочные эффекты. Legacy-код часто делает больше, чем кажется. На один и тот же вызов могут быть навешаны: запись в таблицу аудита, инкремент счётчика в кэше, публикация события в очередь, обновление статуса связанной сущности, инвалидация кэша, дёрганье webhook’а во внешнюю систему. Если в новой реализации воспроизвести только явный путь, скрытые потребители молча перестанут получать данные — и узнают об этом через жалобу бизнеса, а не через ошибку в логах. Поэтому перед выносом любого модуля имеет смысл составить инвентаризацию побочных эффектов: пройтись по коду и логам и выписать каждое нелогичное действие отдельным пунктом чек-листа.

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

Четвертая ошибка — не договариваться с бизнесом. Модернизация не должна быть невидимой «инженерной активностью в стол». Её нужно встраивать в roadmap, объяснять эффект и договариваться о приоритетах. Если бизнес не понимает, зачем команда тратит время на миграцию, работа будет постоянно проигрывать новым фичам.

Пятая ошибка — не удалять старый код. Временное сосуществование старой и новой логики нормально. Вечное сосуществование — нет. Если legacy не удаляется, технический долг не уменьшается, а просто меняет форму.

Шестая ошибка — не удалять фича-флаги после миграции. Флаг, который сыграл свою роль и больше никогда не выключается, превращается в постоянное ветвление в коде. Через год команда не помнит, можно ли удалить такую ветку или там сидит важный edge-case. Через два — кода с такими «мёртвыми» флагами становится больше, чем основной логики. Поэтому каждый флаг должен заводиться с условием удаления («после полной выкатки и двух недель стабильной работы») и иметь ответственного, кто этим удалением займётся.

Отдельно стоит упомянуть организационную сторону. Закон Конвея работает и в обратную сторону: если новый и старый код владеются разными командами с разными приоритетами, миграция будет тормозиться независимо от выбранного паттерна. На время миграции имеет смысл явно проговорить, кто отвечает за переход, и не разделять старую и новую реализации между несовместимыми roadmap’ами.

Компромиссы, к которым нужно быть готовыми

Постепенная модернизация безопаснее Big Bang-переписывания, но она не бесплатна. Некоторое время система будет сложнее, чем раньше. В ней появятся старый и новый код, прокси-слой, фича-флаги, дублирование логики, дополнительные метрики.

Shadow testing увеличит нагрузку на инфраструктуру, потому что часть запросов будет обрабатываться дважды. Команде придется поддерживать дисциплину: документировать контракты, отслеживать флаги, удалять старую реализацию после миграции, поддерживать contract-тесты в актуальном состоянии.

Но это контролируемая сложность. Она распределена во времени и управляется инженерными практиками. В отличие от Big Bang-риска, где команда долго работает с минимальной обратной связью, а потом выкатывает один большой релиз с максимальной неопределенностью.

Когда Strangler Fig особенно оправдан

Постепенная миграция особенно хорошо подходит для систем, где downtime невозможен или слишком дорог. Это финтех, e-commerce, биллинг, мобильные бэкенды с большой аудиторией, высоконагруженные продукты, старые монолиты и системы с большим количеством интеграций.

Если продуктом ежедневно пользуются сотни тысяч или миллионы людей, нельзя позволить себе «переписать и посмотреть, что будет». Нужно менять архитектуру так, чтобы пользователь не замечал процесса миграции.

Этот подход также полезен там, где бизнес продолжает активно развивать продукт. Если фичи нельзя заморозить на полгода, модернизация должна идти параллельно с продуктовой разработкой.

Когда модернизацию лучше не делать

Постепенная миграция — мощный инструмент, но у неё тоже есть стоимость, и иногда правильный ответ — оставить систему как есть. Несколько сценариев, в которых модернизация плохо окупается.

Продукт, который уходит из эксплуатации. Если через год сервис будет выключен или заменён на покупное решение, тратить квартал на его рефакторинг бессмысленно. Достаточно стабилизировать то, что есть.

Модуль, который никто не трогает. Если код десятилетней давности продолжает работать, не падает, не требует изменений и не вызывает инцидентов, его «уродливость» — не повод его переписывать. Цель модернизации — упростить будущие изменения; если будущих изменений нет, цели тоже нет.

Регулируемые системы с тяжёлой ресертификацией. В банковских, медицинских и государственных контурах любое изменение в критичной системе может потребовать повторной сертификации, перепрохождения аудитов, обновления договорной обвязки. В таких условиях стоимость модернизации может на порядок превышать стоимость поддержки текущей реализации, и решение нужно принимать вместе с владельцем продукта и юристами, а не только инженерным составом.

Простой тест: если на вопрос «какой бизнес-сценарий мы откроем после миграции» нет внятного ответа — модернизацию имеет смысл отложить и заняться чем-то другим.

Что получает команда

Главный результат постепенной модернизации — управляемость. Команда начинает лучше понимать систему, контролировать изменения и снижать риск инцидентов.

Появляются понятные контракты, наблюдаемость, практика безопасных релизов, культура удаления старого кода. Разработчики перестают бояться legacy, потому что у них появляется метод, а не только желание «когда-нибудь всё переписать».

Для бизнеса это тоже выгодно. Продукт продолжает развиваться, сроки становятся более прогнозируемыми, риски крупных сбоев снижаются, а технический долг постепенно уменьшается.

Модернизация — это процесс, а не проект

Legacy нельзя «починить за квартал». Если система развивалась годами, она не станет простой после одного рефакторинга. Но её можно системно улучшать.

Strangler Fig Pattern, Branch by Abstraction, feature toggles, shadow testing и аккуратная миграция данных дают рабочую модель: выбрать ограниченный участок, описать контракт, реализовать новую версию, проверить её на реальном трафике, постепенно переключить пользователей и удалить старый код.

Это не самый быстрый путь. Зато он управляемый. А в зрелых продуктах управляемость важнее скорости.

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

Git worktrees позволяют держать несколько рабочих копий одного репозитория на разных ветках — и сейчас эта возможность в тренде. Забавно, что в Git она появилась ещё в 2015 году. Но worktrees действительно удобны, и в этой статье разберёмся, зачем они нужны, чем отличаются от обычных веток и почему внезапно стали популярны.

worktree — это дополнительная рабочая копия репозитория на другой ветке, привязанная к тому же .git.

С их помощью можно переключаться между задачами, не прерывая текущую работу и не используя stash.

Они особенно полезны при параллельной работе с ИИ-агентами и в приложении GitHub Copilot.

У worktrees есть ограничения: раздувание зависимостей, необходимость убирать папки, правила .gitignore и запрет на одновременный checkout одной ветки в нескольких worktrees.

Переключение контекста через ветки и stash

Представьте: вы работаете над задачей и вдруг получаете срочный баг. Нужно срочно переключить контекст.

Сначала, скорее всего, спрячете текущие изменения в stash:

Потом перейдёте на main и обновите её:

Затем создадите ветку с хотфиксом:

Пофиксите, закоммитите и запушите ветку:

После слияния pull request вы вернётесь к компьютеру, подтянете main и удалите ветку с багфиксом:

А потом сможете вернуться к задаче, над которой работали:

Фух. На чём мы остановились?

Переключение туда-сюда, перезагрузка файлов, переустановка node_modules в зависимости от того, что изменилось, — всё это отнимает много сил. Нагрузка от смены контекста серьёзная.

Это базовый пример, но иногда разработчики справлялись с таким хаосом сложными командами git stash или даже несколькими клонами одного репозитория (я сама грешила этим).

А потом появились… worktrees!

Переключение контекста через worktrees

С worktrees вы никогда не покидаете свою ветку и не используете stash, а редактор с вашей текущей фичей остаётся нетронутым.

Эта команда мгновенно создаёт соседнюю папку hotfix-workspace, базирует её на main и создаёт новую ветку hotfix-bug.

Теперь можно открыть эту папку в новом окне редактора (или перейти в неё через cd) и чинить баг. Исходное окно редактора остаётся в том же состоянии, в котором вы его оставили.

Pull request сливаете онлайн, как обычно, а после слияния можно просто удалить временную папку.

Гораздо плавнее! Нет риска конфликтов stash, редактор не перезагружается, и вы действительно можете работать параллельно.

Так почему же сейчас?

Долгое время worktrees были относительно неизвестны. Большинство разработчиков никогда о них не слышали, потому что либо Git GUI не поддерживали их (или относились как к второсортной функции), либо все привыкли к знакомой схеме: feature-ветка, работа, PR, merge и повтор.

Сейчас наша работа изменилась. ИИ заставляет нас работать параллельно больше, чем когда-либо в истории разработки ПО. Разработчики запускают множество сессий одновременно, а «культура код-ревью» растёт быстрее, чем «культура написания кода».

Агенты и люди могут делать больше параллельно с помощью worktrees. Это режим по умолчанию в приложении GitHub Copilot и во многих других современных инструментах.

Агенты и люди могут делать больше параллельно с помощью worktrees.

В чём подвох?

Worktrees решают кучу проблем, но есть нюансы, на которые стоит обращать внимание.

• Раздувание зависимостей: каждая папка worktree требует собственную копию зависимостей проекта. Если запускать npm install или pip install в нескольких worktrees, диск может быстро закончиться.
• Управление папками: нужно удалять папки worktree, чтобы со временем не засорять родительский каталог. Приложение GitHub Copilot часто делает это за вас, но если вы работаете в терминале, придётся следить самостоятельно.
• Требования к глобальному .gitignore: если создавать worktree внутри основного репозитория, их нужно вручную добавить в .gitignore, чтобы случайно не закоммитить. Можно создавать worktree за пределами основного репозитория (GitHub Copilot делает это по умолчанию), но это стоит учитывать.
• Ограничение «одна ветка»: Git не позволяет одновременно checkout’ить одну и ту же ветку в двух разных worktrees, чтобы избежать повреждения данных.

Как использовать git worktrees в приложении GitHub Copilot?

Отличный вопрос! Здорово, что там всё работает «из коробки». Когда вы открываете приложение, на главном экране есть выпадающий список, который спрашивает, где запускать новую сессию. По умолчанию выбран новый worktree.

Когда вы запускаете новую сессию, можно нажать на имя сессии вверху приложения и увидеть (забавное!) сгенерированное имя вашего worktree, а также путь, где он находится, проект, для которого он создан, и сведения о внесённых изменениях.

Проще простого!

Стоит ли использовать worktrees?

Я дам вам самый senior-ответ, который только можно: зависит от ситуации! Вам может быть удобнее работать по-другому. Возможно, вы не так много работаете параллельно и привыкли к ментальной модели веток и stash. Возможно, теперь вы будете использовать только worktrees. А может, захотите и то, и другое!

Мир у ваших ног, и попробовать всё это можно уже сегодня в приложении GitHub Copilot.

Об авторе. Cassidy Williams — старший директор по адвокации разработчиков в GitHub. Она создаёт ПО, консультирует стартапы и учит разработчиков строить лучше. Подписаться на её еженедельную рассылку можно на cassidoo.co/newsletter.

Выводы

Git worktrees — способ работать с несколькими ветками одновременно, не прерывая текущую задачу и не рискуя запутаться в stash. Они особенно удобны при параллельной работе с ИИ-агентами и встроены в приложение GitHub Copilot по умолчанию. Попробуйте — возможно, именно они упростят ваш рабочий процесс.

Для владельцев маркетплейсов, игровых магазинов и сервисов автоматизация оплаты сегодня становится не преимуществом, а обязательным условием масштабирования. Именно поэтому API-интеграции для цифровых платежей и автоматического пополнения игровых сервисов стали ключевым технологическим инструментом в индустрии.

Почему ручная обработка больше не работает

Большинство начинающих проектов стартуют одинаково: оператор вручную проверяет оплату, подтверждает заказ и отправляет ключ или проводит пополнение аккаунта. Пока заказов немного — схема кажется рабочей. Но после роста трафика начинаются проблемы:

• задержки обработки;
• ошибки операторов;
• потеря заказов;
• возвраты из-за долгого подтверждения;
• невозможность работать 24/7;
• высокий риск мошенничества.

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

Именно поэтому современные площадки переходят на автоматизированную архитектуру: платежный шлюз + API поставщика цифровых услуг + система мгновенной обработки заказов.

Почему бизнес выбирает GGPay

На фоне растущего рынка особое внимание получают сервисы, которые совмещают удобный API, стабильную инфраструктуру и понятную финансовую модель.

Одним из таких решений сегодня является GGPAY — сервис для пополнения Steam и других цифровых платформ с поддержкой автоматизированной обработки платежей.

Платформа ориентирована как на конечных пользователей, так и на владельцев цифровых магазинов, маркетплейсов и игровых сервисов. Среди ключевых преимуществ:

• стабильная работа API;
• автоматическое проведение платежей;
• поддержка популярных способов оплаты;
• низкие комиссии;
• высокая скорость зачисления;
• работа 24/7;
• удобная интеграция для сайтов и Telegram-проектов.

Для владельцев цифровых площадок особенно важно, что подобные сервисы позволяют быстро запускать автоматизированную продажу без необходимости строить собственную сложную платежную инфраструктуру с нуля.

Как устроена API-интеграция цифровых платежей

С технической точки зрения система выглядит достаточно просто, хотя внутри скрывается сложная логика маршрутизации и проверки транзакций.

Типовой процесс выглядит следующим образом:

1. Пользователь выбирает цифровой товар или пополнение.
2. Сайт формирует заказ.
3. Платежный шлюз принимает оплату.
4. После подтверждения транзакции сервер обращается к API поставщика.
5. API выполняет пополнение или выдает цифровой ключ.
6. Клиент получает результат автоматически.

Подобная модель давно используется в международной игровой индустрии и интегрируется через REST API, callback-уведомления и защищенные webhook-системы.

Главное преимущество такой схемы — отсутствие ручной обработки. Бизнес получает возможность масштабироваться практически без увеличения штата.

Какие задачи решает API для цифровых товаров

Современные API-платформы позволяют автоматизировать практически весь цикл продажи:

• пополнение Steam;
• продажу игровых ключей;
• выдачу gift card;
• оплату подписок;
• работу с региональными балансами;
• массовую обработку заказов;
• автоматический возврат;
• мониторинг статусов транзакций;
• защиту от дублирования платежей.

Для крупных площадок особенно важна возможность работать с несколькими поставщиками одновременно. Это позволяет распределять нагрузку, снижать комиссии и поддерживать стабильность даже во время пикового спроса.

На что обращать внимание при выборе API-партнера

Ошибка многих проектов — выбор поставщика исключительно по размеру комиссии. На практике стабильность API намного важнее разницы в 1–2%.

При выборе сервиса необходимо оценивать:

1. Скорость обработки

Для игровых сервисов критична мгновенная выдача. Пользователь не готов ждать 10–15 минут после оплаты.

2. Аптайм инфраструктуры

Если API регулярно падает во время крупных распродаж Steam — бизнес теряет деньги и репутацию.

3. Наличие webhook и callback-систем

Это основа автоматизации статусов платежей.

4. Документация

Качественная документация сокращает время интеграции в разы.

5. Поддержка популярных способов оплаты

СБП, банковские карты, криптовалюты, электронные кошельки — современный рынок требует гибкости.

6. Защита от мошенничества

Антифрод-механизмы и валидация заказов особенно важны в сегменте цифровых товаров.

Почему рынок активно переходит на автоматические пополнения Steam

Steam остается крупнейшей игровой платформой мира, а пополнение кошелька — одним из самых востребованных цифровых продуктов в СНГ и Восточной Европе.

После изменений в международной платежной инфраструктуре спрос на альтернативные способы пополнения вырос кратно. На этом фоне появились специализированные сервисы, работающие через API-интеграции и автоматические платежные шлюзы.

Сегодня пользователи ожидают:

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

Именно поэтому автоматизированные сервисы показывают значительно более высокую конверсию по сравнению с полуавтоматическими решениями.

Как выглядит современная архитектура цифрового магазина

Профессиональная инфраструктура обычно включает несколько уровней:

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

Дополнительно многие проекты подключают аналитические сервисы, отслеживающие:

• процент успешных транзакций;
• скорость выдачи;
• причины отказов;
• нагрузку по регионам;
• эффективность платежных методов.

Такой подход позволяет масштабировать платформу практически без ограничений.

Какие технологии будут доминировать дальше

Рынок цифровых платежей продолжит двигаться в сторону полной автоматизации. Уже сейчас активно развиваются:

• direct top-up через Steam ID;
• мультивалютные API;
• криптовалютные расчеты;
• AI-антифрод;
• распределенные платежные системы;
• автоматические системы маршрутизации транзакций.

При этом требования пользователей становятся только жестче: скорость, надежность и прозрачность превращаются в стандарт индустрии.

Заключение

API-интеграция оплаты для цифровых ключей и игровых сервисов — это уже не дополнительная функция, а фундамент современного digital-бизнеса. Автоматизация позволяет масштабировать продажи, снижать издержки, минимизировать ошибки и обеспечивать мгновенную выдачу цифрового товара.

Именно поэтому проекты, работающие в сегменте игровых пополнений и цифровых товаров, всё чаще выбирают готовые инфраструктурные решения вместо ручной обработки заказов.

А сервисы вроде GGPAY становятся частью новой экосистемы цифровых платежей, где скорость обработки, стабильность API и удобство пользователя напрямую влияют на рост бизнеса и удержание аудитории.

Реклама. Рекламодатель: ОсОО «НОВАПЭЙ», ИНН:9909710276, erid: 2SDnjf2S7a2

1. Как я утонул в генерациях
2. Экзамен вместо «прыжков» по сервисам
3. Небольшой технический конвейер
4. Зачем цифры важнее впечатлений
5. Простой тест на форматы
6. Как ведут себя Riverflow, Flux и Seedream
7. Отчёты, артефакты и спокойная аналитика
8. Сценарий «восемь формулировок»
9. Зрелый подход к выбору AI

В прошлой статье я рассказывал, как собрал тестовый стенд для AI‑генерации. Теперь — про то, как превратил его в живой процесс с разными сценариями и метриками.

1. Как я утонул в генерациях

Я осознал что в очередной раз листал чат и не мог найти тот самый удачный вариант обложки.

Ситуация повторялась по одному и тому же шаблону. Запускаю один сервис — получаю результат, морщу лицо и сразу иду в другой. Там промпт приходится переформулировать: движок по-другому читает слова. В третьем генераторе наконец складывается приятная композиция, но детализация рушит весь смысл. Через пару дней на диске лежит россыпь PNG, а я уже не понимаю, где оказался осознанный успех, а где просто повезло. В какой-то момент я сказал себе: стоп. Случайные «попробую тут, попробую там» не ведут никуда.

2. Экзамен вместо «прыжков» по сервисам

Тогда я придумал простое правило. Любой сервис, который претендует на место в моём рабочем наборе, должен пройти экзамен. Не приятную беседу с общими вопросами, а одинаковый для всех, жёсткий сценарий. Без исключений и любимчиков.

3. Небольшой технический конвейер

Реализация получилась до обидного простой. Node.js, TypeScript, запуск через tsx. Список моделей вынесен в отдельный конфиг, API-ключ лежит в .env, а команды запуска выглядят вроде npm run test:niche или npm run test:collage-2x2-eight-prompts. Я взял творческий хаос и сложил его в аккуратный pipeline.

Дальше всё происходит автоматически: запускаешь тест — и один и тот же набор задач последовательно проходит через всех кандидатов. Мой вклад заканчивается на нажатии Enter.

4. Зачем цифры важнее впечатлений

Зачем вообще так усложнять? Потому что мантра «любая нейросеть — она и есть нейросеть» на практике не работает. Разброс колоссальный. Один сервис очень аккуратно держит геометрию кадра, но мелкие детали превращает в мыло. Другой рисует фактуру так, что хочется печатать и вешать, но при запросе «коллаж 3×3 с чёткими границами» внезапно решает творчески переосмыслить сетку. Третий стабильно отвечает и по времени, и по предсказуемости, но на сотне запросов выписывает такой чек, что хочется закрыть вкладку.

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

5. Простой тест на форматы

Возьмём самый базовый пример — проверка соотношения сторон. Формулировка элементарная: закат над горами, три варианта — 3:4, 1:1 и 16:9. Казалось бы, минимальный уровень адекватности. Но нет.

Достаточно пробежать глазами столбец со статусом. Три запроса — три быстрых проверки «на глаз». Там, где на 3:4 и 16:9 горит FAIL, модель откровенно игнорирует задачу и рисует квадрат или удобный для себя формат. И это при том, что промпт простейший: не сложная сцена, не коллаж — всего лишь «закат, горы и нужная рамка».

6. Как ведут себя Riverflow, Flux и Seedream

Если посмотреть на результаты, riverflow-v2-pro аккуратно соблюдает все три формата. Но за эту аккуратность приходится платить временем: портретная картинка генерируется около 360 секунд. Шесть минут — роскошь, если у вас в руках горящий дедлайн. Упрощённая версия, riverflow-v2-fast, выдаёт правильные форматы за секунды и остаётся в адекватных рамках по времени — это уже инструмент для реальных задач.runware+2

С моделями Flux история другая. Почти вся линейка black-forest-labs стабильно промахивается по нестандартным форматам: колонка «Соотношение» упорно показывает 4/3 или 1/1, хотя в запросе чётко указано «16:9, wide landscape». Относительно ровно ведёт себя только flux.2-max, который хотя бы честно выдаёт квадрат, но проблемы с другими соотношениями никуда не деваются.github+1

Seedream-4.5 от Bytedance, напротив, поражает скоростью: ответы прилетают за 7–8 секунд, но модель регулярно игнорирует заданный формат и возвращает квадрат 2048×2048. Для макета, привязанного к конкретным пропорциям — сторис, постера или баннера — такая «быстрота» только ломает всю вёрстку.eachlabs+1

7. Отчёты, артефакты и спокойная аналитика

Вся эта конструкция нужна ради пары простых эффектов. Каждый запуск сохраняет статус, итоговый размер, время генерации и, где это важно, стоимость. После завершения прогона скрипты собирают HTML-отчёт. Открываешь его в браузере — и на одном экране сразу видно, кто действительно справился, а кто только шумит.

Особенно сильно это помогает в задачах, где критична композиция: нужна ровная сетка 2×2 или 3×3 без самодеятельности в духе «я тут чуть подвину, так красивее». Это как раз те случаи, когда от сервиса нужна дисциплина, а не внезапные художественные «инициативы».

8. Сценарий «восемь формулировок»

Отдельный пласт наблюдений даёт сценарий «восемь формулировок» (collage-2x2-eight-prompts). Суть задачи не меняется, контент остаётся одним и тем же. Я варьирую только подачу: где-то пишу запрос грубо и коротко, где-то — щадяще и структурно, местами добавляю лишний контекст.

На этом месте становится видно, как модель реагирует не на саму тему, а на стиль запроса. Одна и та же нейросеть спокойно выдерживает строгое техническое ТЗ и проваливается при формулировке «сделай красиво, сам понимаешь». После таких тестов по-другому относишься к промптам: начинаешь формулировать точнее, понимая, какая модель как «слушает» текст. И внезапно исчезают загадки в духе «почему здесь получилось, а там всё развалилось».

9. Зрелый подход к выбору AI

Главный вывод из всей этой истории довольно приземлённый. Выбирать AI-сервисы по рекламе, по восторженным постам в Telegram или по одному удачному демо-кадру — путь к разочарованию. Их нужно ставить в одинаковые условия. Прогонять по своим реальным задачам, а не по чужим презентациям. Сохранять результаты и сравнивать их по конкретным цифрам.

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

, чтобы приватный ключ жил внутри браузерного crypto runtime и его нельзя было экспортировать в байты. Но у этого подхода есть практическая сложность: ключи нужно переживать между перезагрузками страницы, синхронизировать с IndexedDB, аккуратно восстанавливать состояние устройства и не сломать UX.

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

Ключевой момент: backend всё равно не получает приватные ключи и не может расшифровать сохранённые ciphertext-конверты. Но защита ключей на клиенте — отдельная задача, и её нельзя честно замалчивать.

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

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

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

Для чата где у каждого по 2 устройства — 4 конверта на одно сообщение. Для группы из 10 человек — потенциально 20 конвертов. Это нормально, это цена безопасности.

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

Простое решение. Но чтобы к нему прийти нужно было полностью принять идею что сервер здесь просто не при делах — и перестать пытаться решить задачу на его стороне.

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Мы остановились на открытом симуляторе InferSim от Alibaba. Он умеет считать TTFT, TPOT и пропускную способность без запуска реального инференса. Но из коробки поддерживает только несколько топовых GPU и фиксированный набор моделей — для наших сценариев этого было недостаточно. Пришлось дорабатывать.

Как устроен InferSim

В основе симулятора — двухфазная схема. Сначала на целевом железе запускаются микро-бенчмарки: измеряется реальная производительность на типовых операциях внимания и матричных умножениях. Получается таблица коэффициентов Model FLOPs Utilization (MFU) — сколько процентов от теоретического максимума выдаёт конкретная карта на конкретной операции. Затем, уже без доступа к GPU, симулятор на основе этих MFU и аналитической модели вычисляет задержки. Именно такой подход даёт более точные предсказания, чем оценка по паспортной пропускной способности памяти.

Добавляем своё железо

Первым делом мы внесли в hardware/gpu.py поддержку MetaX C500 64GB. Характеристики добавляются через dataclass-экземпляры:

После этого c500 попадает в словарь gpu_map, и симулятор запускается с ключом --device-type C500 --world-size 2. Значения FLOPS и пропускной способности пришлось оценивать по косвенным источникам — производитель не публикует точных цифр. Позже планируем уточнить их через бенчмаркинг на реальном оборудовании. Таким же способом добавили Nvidia 1xH100 и A100.

Конфигурация моделей и одна болезненная ошибка

Симулятор ожидает стандартный config.json в формате Hugging Face. Для Qwen3-32B подготовили файл qwen3_32b_config.json:

Ключевой момент — правильное значение head_dim. У Qwen3-32B оно равно hidden_size / num_attention_heads = 5120 / 64 = 80. У нас ушло некоторое время, чтобы понять, почему симулятор выдаёт невалидные результаты: изначально в конфиге стояло значение 128. Пока не исправили — KV-кеш переоценивался, и метрики улетали в неадекватные цифры. После исправления всё встало на свои места.

Позже добавили поддержку Qwen3.5‑9B с её гибридной архитектурой, построенной на чередовании Gated DeltaNet и Gated Attention. Главная особенность модели в том, что около трёх четвертей слоёв не создают привычного KV‑кеша, а используют линейное внимание – компактное скрытое состояние, которое лишь обновляется с каждым новым токеном, не увеличиваясь в объёме. Это кардинально снижает расход памяти на длинных контекстах, но привносит и свою цену: на коротких дистанциях такая модель проигрывает в скорости Prefill, потому что Gated DeltaNet работает последовательно и хуже утилизирует матричные вычисления GPU.

Симулятор изначально не умел различать слои двух типов и считал весь KV‑кеш одинаково. Чтобы поддержать Qwen3.5, пришлось доработать расчёт задержек в классе HybridModel: теперь он отдельно обсчитывает full‑attention‑слои с полным кешем и linear‑attention‑слои без кеша, используя параметры num_full_attn_layers и num_linear_attn_layers из конфигурации. В директорию проекта models добавили hybrid_model.py, в котором сделали дополнительные расчёты:

Без такой дифференциации симулятор для Qwen3.5‑9B показывал E2E порядка 2 500 секунд вместо реальных нескольких секунд – та ошибка, которую мы долго отлавливали.

Визуализация и эксплуатация

Чтобы не разбирать каждый раз текстовый вывод InferSim, сделали веб-интерфейс на Streamlit. Симулятор дёргается через subprocess, результаты парсятся из stdout и визуализируются:

• тепловые карты задержек (Prefill, Decode, E2E Total) для разных длин входных и выходных токенов;
• анализ RPS с расчётом требуемой параллельности и сравнением с доступной памятью;
• информация о занятой памяти в формате «X ГБ из Y ГБ».

Кэширование через @st.cache_data позволило избежать повторных запусков симуляции при неизменных параметрах. Интерфейс получился достаточно удобным, чтобы даже коллеги без погружения в командную строку могли осмысленно сравнивать конфигурации.

Приложение упаковано в Docker и лежит в репозитории на GitHub. Сервисы — сам Streamlit и Nginx в качестве обратного прокси с SSL-терминацией и базовой HTTP-аутентификацией. Деплой на VDS автоматизирован через GitHub Actions: собрали образ, отправили на сервер, перезапустили контейнеры. SSL-сертификаты Let's Encrypt обновляются по cron.

Что в итоге

Адаптированный InferSim не претендует на абсолютную точность — она ограничена качеством бенчмарков и коэффициентов MFU. Но инструмент позволяет избежать грубых ошибок при планировании, что в условиях ограниченного доступа к GPU и их высокой стоимости само по себе немало. Мы продолжаем калибровку симулятора и готовим обновлённые конфигурации для следующих моделей.

Репозиторий проекта открыт, будем рады замечаниям и предложениям от тех, кто решает схожие задачи.

Jujutsu (сокращённо jj) — система контроля версий, совместимая с Git по протоколу, но с другой моделью коммитов: конфликты — сущность первого класса, commit и rebase — базовые операции, immutable и mutable коммиты отделены. В посте — перевод статьи Корбри с HN (249 points): зачем нужны megamerges, как их собирать и как поддерживать в актуальном состоянии через алиасы jj.

Пост написан для пользователей Jujutsu среднего уровня и для гитовых пользователей, которым любопытен jj. Специальные команды приведены в оригинальном виде (их не локализуют), пояснения — в комментариях к коду. Ключевые термины jj: revset — язык запросов к графу коммитов (аналог Git-revisions, но расширенный); bookmark — аналог ветки в Git, но не двигается автоматически за рабочей копией; WIP — work in progress, незавершённые изменения.

• Megamerge — octopus merge (коммит с тремя и более родителями), куда вы включаете все рабочие ветки: фичи, багфиксы, PR, чужие ветки-зависимости, локальные инструменты. Вы работаете поверх него.
• Выгода: всегда видите сумму всех изменений разом; почти не ловите сюрприз-конфликты на пуше; быстро переключаетесь между задачами (просто редактируете код); можно легко делать drive-by-фиксы.
• Собрать просто: jj new x y z + jj commit -m megamerge. Megamerge в remote не пушится — пушатся только ветки, из которых он собран.
• Сабмит WIP-изменений: jj absorb (автоматически разбрасывает строки по «родным» коммитам) и jj squash --to X --interactive (вручную выбирать куски).
• Поддержка актуальности — алиас restack: ребейзит только ваши mutable-коммиты на trunk, оставляя в покое чужие ветки.

Merge-коммиты в jj: обычный коммит с несколькими родителями

Если вы обычный гит-пользователь (или пользователь Jujutsu, который ещё не дошёл до продвинутых процессов), возможно, вы удивитесь: в merge-коммите нет ничего особенного. Это не специальный случай с отдельными правилами — это обычный коммит, у которого несколько родителей. Он даже не обязан быть пустым.

Легенда вывода jj log: @ — текущая рабочая копия; ○ — mutable-коммит; ◆ — immutable-коммит (обычно trunk); ├─╮ — граф связей.

Удивит и второе: merge-коммиты не ограничены двумя родителями. Мерджи с тремя и более родителями в сообществе неофициально называют octopus merge. И если вы думаете: «в каком мире мне может понадобиться слить больше двух веток?» — на практике эта идея очень мощная. Именно octopus merges дают весь megamerge-воркфлоу.

Так что же такое megamerge

Суть в том, что в megamerge-воркфлоу вы редко работаете прямо поверх тика одной ветки. Вместо этого вы создаёте octopus merge (его и называем megamerge) как дочерний коммит от каждой рабочей ветки, которая вам важна. Это могут быть багфиксы, фича-ветки, ветки, ждущие PR, чужие ветки, от которых зависит ваш код, локальные окружения и даже приватные коммиты, которые не принадлежат ни к одной ветке. Всё, что вам важно, входит в megamerge. Главное помнить: megamerge не пушится в remote — пушатся только ветки, из которых он собран.

Если звучит как много — нормально. Вы же знаете, сколько сил уходит на смену контекста при возврате к старому PR. Но такой подход даёт несколько реально ценных вещей:

• Вы всегда работаете поверх суммы всех своих изменений. Если ваша рабочая копия собирается и запускается — вся ваша работа гарантированно согласуется друг с другом.
• Почти не встречаются сюрприз-конфликты. В Jujutsu конфликты и так first-class (их не нужно «решать прямо сейчас»), а в megamerge-воркфлоу вы постоянно сливаете свои изменения — поэтому на стороне удалённого хостинга (GitHub/GitLab) конфликтов не возникает. Иногда проблемы случаются с изменениями контрибьюторов, но на практике это редкость.
• Намного меньше трения при переключении задач. Поскольку вы всегда работаете поверх megamerge, не нужно ходить в VCS — можно просто пойти править нужный код. Легко делать маленькие PR для попутных рефакторов и фиксов.
• Проще держать ветки актуальными. Небольшой алиас — и весь megamerge обновляется относительно trunk одной командой rebase. Разберём ниже.

Как собрать megamerge

Старт — простой: новый коммит с каждой нужной веткой в качестве родителя. Автор любит давать этому коммиту имя и оставлять пустым:

Получаете пустой коммит поверх всего. Вот тут и идёт работа. Всё, что выше megamerge, считается WIP. Можно сплитить, создавать несколько веток из megamerge — всё, что хотите. Всё, что вы напишете, будет опираться на сумму содержимого megamerge — как и задумывалось.

В какой-то момент вы будете довольны результатом — и встанет вопрос:

Как затем сабмитить изменения

Как дотащить изменения до megamerge — зависит от того, куда они должны попасть. Основной инструмент — команда absorb: она сама определяет, в какой mutable-коммит ниже по дереву должен пойти каждый хунк или каждая строка, и автоматически разбрасывает их по нужным коммитам. «Каждый раз выглядит как фокус — логика absorb прозрачна: команда смотрит, в каком коммите ниже по дереву впервые появилась каждая изменяемая строка, и отправляет её туда». Это одна из ключевых фич Jujutsu, благодаря которой megamerge-воркфлоу работает плавно.

Но Jujutsu — красивый кусок софта, и у него есть автоматика. Команда absorb сделает бо́льшую часть работы за вас: определит, в какой mutable-коммит ниже по дереву должен пойти каждый ваш хунк или каждая строка, и автоматически их туда сквошит. «Каждый раз ощущается как магия — и не та чёрная магия, в которой ничего не разобрать, а хорошая, понятная». Это одна из ключевых фич Jujutsu, благодаря которой megamerge-воркфлоу вообще работает плавно.

Absorb не всегда ловит всё, но обычно укладывает около 90% изменений. Остальное — либо ручной squash --to (отправляет изменения в конкретный коммит), либо squash --to X --interactive (для выборочного переноса кусков). Если WIP-коммит содержит изменения для нескольких целей — сначала сплит командой split, либо тот же --interactive.

Если изменения должны попасть в новый коммит — не сильно сложнее. Если коммит относится к одной из ваших веток, просто ребейзим и двигаем bookmark:

Разложим этот rebase, чтобы было понятнее:

А если вы начали работу над совершенно новой фичей или наткнулись на баг — ещё проще. С парой алиасов можно легко добавить новый материал в megamerge:

Короткое пояснение, что делает closest_merge(to):

С этим revset-алиасом stack берёт произвольный revset и вставляет его между trunk() (основной веткой разработки) и megamerge:

Это полезнее, если несколько стеков изменений хочется включить параллельно. А если стек один, есть ещё один алиас, который подхватывает весь стек после megamerge:

Этот алиас не требует аргументов. Достаточно накоммитить и ввести stage:

Последний кусок пазла — неприятная реальность: есть ещё другие люди.

Как держать всё это в актуальном состоянии

Хороший вопрос — автор потратил пару месяцев, чтобы ответить на него в общем виде. У Jujutsu есть простой способ ребейзить всю рабочую ветку на основную ветку:

Но это работает, только если всё ваше рабочее дерево (worktree) состоит только из ваших изменений. Когда в графе есть коммиты, которые вам не принадлежат (untracked bookmark или чужие ветки), Jujutsu остановится, чтобы защитить их от перезаписи.

Решение — ребейзить только те коммиты, которыми вы реально управляете. Спасибо Стивену Дженнингсу за отличный revset:

Вместо того чтобы пытаться ребейзить всё дерево (как делает jj rebase --onto trunk()), этот алиас трогает только коммиты, которые можно двигать. Чужие ветки и работа поверх них остаются на месте. Флаг --simplify-parents заодно убирает лишние рёбра, которые могут остаться после ребейза. У автора эта команда не ломалась ни разу — даже на мегамерджах с девятью родителями разных контрибьюторов.

TL;DR: рабочая конфигурация

Megamerges в Jujutsu — рабочий способ уложить несколько параллельных задач в одно рабочее дерево. Для полноценной эргономики добавьте в конфиг через jj config edit --user:

Краткая шпаргалка по командам:

Ещё раз: megamerge не задуман для пуша в remote — это удобный способ увидеть всю картину целиком. Ветки всё равно публикуются отдельно, как обычно.

Megamerges подходят не всем — автор рассказывает, что получал испуганные взгляды, показывая своё рабочее дерево. Но, попробовав их один раз, вы с большой вероятностью обнаружите, что переключаетесь между задачами почти без усилий.

Дополнительно: замечания автора

• Флаг --simplify-parents в restack важен — он вычищает избыточные рёбра (если есть A→B→C и A→C, simplify-parents удалит A→C).
• stage использует closest_merge(@)+::, а не closest_merge(@).. — оператор x.. эквивалентен ~::x и включает всё, что не является предком x. Это может затянуть лишнее.
• В Git merge-коммиты, куда вносят изменения поверх разрешения конфликтов, называют evil merge. В Jujutsu такие мерджи уже не «злые» — модель Jujutsu устроена более консистентно.
• Алиасы Jujutsu. Есть несколько типов: revset-алиасы (кастомные функции, которые возвращают коммиты через revset language); command-алиасы (расширяют стандартные команды); template-алиасы (меняют формат вывода jj в терминале через templating language); fileset-алиасы (работают с файлами через fileset language).
• Концепция mutable/immutable. Mutable-коммиты — те, что можно менять на регулярной основе. Это в основном lint (есть флаг --ignore-immutable), но он помогает не влипнуть. Алиасы mutable() и immutable() выбирают соответствующие коммиты.

FAQ

Выводы

Megamerge-воркфлоу убирает одну конкретную боль: необходимость помнить, какие ветки с чем конфликтуют, и постоянно переключать контекст. Базовая схема: octopus merge как «рабочая площадка», absorb и squash для отправки изменений в нужные коммиты, restack для поддержания актуальности. Ничего магического — обычные коммиты и revsets, собранные в удобный процесс. Кто работает в воркфлоу Trunk-Based Development, увидит знакомые паттерны — megamerge хорошо с ними сочетается.

Оригинал статьи: isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-and-profit. Обсуждение на Hacker News: news.ycombinator.com/item?id=47841129. Официальная документация Jujutsu: jj-vcs.github.io/jj.

Раньше стэки делали сторонними инструментами: облачный сервис Graphite, консольные клиенты ghstack (от Meta) или spr. Все они симулировали стэки поверх обычного GitHub и ломались на ребейзах, merge queue и branch protection. Нативная реализация решает именно эти проблемы — о том, что с ней не так на старте и кому есть смысл пробовать прямо сейчас, разбираемся ниже.

• Статус: Private Preview, нужен waitlist для репозитория
• Что внутри платформы: stack map в UI, cascading rebase, корректная работа branch protection и merge queue
• CLI: расширение gh stack открыто в гитхабе, алиас gs — команды init, add, push, submit
• ИИ-агенты: npx skills add github/gh-stack учит Claude Code и Codex разбивать задачи на слои
• Кому идти сразу: командам с регулярными PR 1500+ строк или большими диффами от ИИ-ассистентов
• Кому подождать: тем, кто уже на Graphite или делает в основном PR на 200 строк

Что такое stacked PRs

Stacked PR (стек пулл-реквестов) — это цепочка PR, где каждый таргетит не main, а ветку PR ниже. Вместо одного огромного пулл-реквеста с пятью разными по смыслу изменениями вы делаете пять маленьких PR, которые читаются независимо и строятся один на другом.

Пример. Вы делаете фичу, которая требует нового API, роутов и фронтенда. Обычно это превращается в PR на 2000 строк, где ревьюер сначала вникает в API, потом забывает про него, когда смотрит роуты, путается в фронтенде и в итоге пишет «LGTM, не читал». Со стэком:

• PR #1 — auth-layer: новый API-слой (200 строк, одна тема)
• PR #2 — api-routes: роуты на базе auth-layer, таргетит ветку PR #1
• PR #3 — frontend: UI на базе роутов, таргетит ветку PR #2

Ревьюеры читают по одному PR, дают фидбек по конкретной теме, и вы мержите всё разом, когда каждый слой одобрен. Подход называется «small PR culture» — мы уже разбирали, почему команды переосмысляют формат пулл-реквестов.

Что GitHub сделал на уровне платформы

Сторонние тулы уже давно давали стек на Git-уровне, но работали поверх обычного GitHub и ломались на ребейзах, merge queue и branch protection. Нативная поддержка закрывает эти углы:

• Stack map в UI — навигация между PR прямо в интерфейсе, видно статус каждого слоя сразу
• Cascading rebase — ребейзнули PR внизу стэка, один клик — и все PR выше автоматически ребейзятся
• Branch protection — правила (ревью-апрув, passing checks) применяются против финальной целевой ветки (обычно main), а не против промежуточной
• CI — прогоняется для каждого PR в стэке так, будто он уже таргетит финальную ветку (не промежуточную)
• Merge queue — очередь GitHub, которая последовательно ребейзит и мерджит PR. Теперь понимает стэки: можно ставить в очередь как весь стэк, так и его часть
• Частичный мердж стэка — если одобрены только нижние два PR, можно слить их, а верхние оставить на доработку
• API — управление стэками через GraphQL и REST, интеграция с вашими CI-тулами

CLI gh stack: что внутри

CLI — опциональное расширение к стандартному gh. Сокращает рутину: не надо вручную создавать ветки, проставлять base, делать серию rebase. Базовые команды следуют той же логике, что и современные workflow поверх Git — работать мелкими слоями и синхронизироваться автоматически.

Базовый сценарий от GitHub:

Дальше — работа как с обычными PR, только с визуальной картой стэка. Хотите ребейзнуть auth-layer на свежий main — gs rebase, и вышележащие слои автоматически подтягивают новую базу.

Интеграция с ИИ-агентами

GitHub явно заточил stacked PRs под сценарий совместной работы с ИИ-агентами. Skills — это документированный формат инструкций для кодовых ассистентов: одна папка с markdown-файлами и примерами, которую агент читает и использует как расширение своего поведения. Команда npx skills add github/gh-stack добавляет такой скилл для Claude Code, OpenAI Codex и других агентов, которые поддерживают формат.

Скилл учит агента двум вещам: брать большую задачу и заранее разбивать её на слои (вместо того чтобы генерировать один огромный коммит), и работать поверх существующего стэка — добавлять новые слои или чинить нижние. Это решает одну из главных проблем ИИ-разработки: агент делает «всё сразу», ревью превращается в кошмар, а откатить часть изменений невозможно. Похожая мотивация была у Copilot-агента, который собирает PR сам, но без стэков он быстро упирается в размер диффа.

Как попасть в Private Preview

1. Зайти на github.github.com/gh-stack и записаться в waitlist (кнопка «Sign up for the waitlist»)
2. Дождаться, пока GitHub включит фичу для вашей организации или репозитория — точных сроков они не называют
3. Включить в настройках репо: появится новая секция Stacked PRs в Settings → Pull Requests
4. Поставить расширение CLI: gh extension install github/gh-stack

CLI-расширение распространяется свободно — его можно поставить уже сейчас из открытого репозитория github/gh-stack. Но README расширения предупреждает: без включённого Private Preview на стороне сервера команды gs push и gs submit упрутся в API, который отвечает 404 или ошибкой доступа. Поставить CLI и посмотреть gh stack --help можно, реально прогонять стэки — только после активации preview в репозитории.

Зачем это, если есть Graphite, ghstack и spr

Существующие решения делятся на две группы. Graphite — коммерческий сервис: у него свой веб-интерфейс, бэкенд и платные тарифы, он синхронизирует стэк через GitHub API. Ghstack (Meta) и spr (Cord) — консольные клиенты: держат локальный граф стэка и пушат PR напрямую. Общее у них одно — стэк живёт где-то вне GitHub, а синхронизируется с ним через API.

Из-за этого все они ломаются в одном классе сценариев: когда кто-то из команды мержит через веб-интерфейс, делает force-push из терминала или запускает merge queue, локальный граф CLI или состояние сервиса Graphite разъезжаются с реальностью — и стэк приходится чинить руками.

Нативная реализация снимает этот класс проблем: стэк живёт на стороне сервера GitHub, UI и CLI синхронизируются с ним автоматически. Branch protection, merge queue, CI — всё работает без костылей. Для базового сценария «разбить большую диффу на стэк и слить её» стороннее звено становится необязательным.

У сторонних тулов остаётся ниша: автогенерация описаний PR через ИИ у Graphite, интеграция с Jira и Linear, аналитика по времени ревью — всё это GitHub не закрывает. Если вы уже платите Graphite за эту часть — ничего не сломается, тулы совместимы со Stacked PRs на уровне API.

Для российских разработчиков: GitHub работает с ограничениями для аккаунтов, подключённых из РФ с 2022 года — возможны блокировки при создании организаций и проблемы с оплатой приватных репозиториев. Нативные Stacked PRs становятся особенно полезны, если переходить на GitFlic, GitVerse или self-hosted GitLab, где аналогов стэков на платформенном уровне пока нет — но CLI-клиенты ghstack и spr работают и на них.

Что делать прямо сейчас

Если ваша команда регулярно сталкивается с ревью на 1500+ строк, PR, которые висят неделями, или большими диффами от ИИ-ассистентов — встаньте в waitlist, поставьте CLI gh extension install github/gh-stack и подготовьтесь к следующей крупной задаче. Пока ждёте активации — попробуйте разбить текущую большую задачу руками через последовательные PR с правильными base-ветками: это работает и в обычном GitHub, а CLI потом сделает то же самое автоматически.

Если вы уже на Graphite и довольны — переезд имеет смысл после выхода фичи из Private Preview и появления миграционного сценария. Небольшим командам с PR на 200 строк фича пока не нужна: инвестиции в стэки окупаются там, где большие задачи — частая история.

Нативная поддержка закрывает больную для крупных команд зону: большие изменения теперь можно разбивать без костылей, а ревью — делать по смыслу, а не по количеству строк.

Источники: официальный анонс GitHub Stacked PRs, репозиторий CLI-расширения, обсуждение на Hacker News.

Это адаптированный перевод учебника Стива Клабника (автор «The Rust Programming Language») про jj — с объяснением ключевых концепций и тем, чем они отличаются от Git. Автор сам пришёл к jj, попробовав его после статьи Криса Крайко, и признаётся: это редкий случай, когда инструмент одновременно проще и мощнее старого.

Git-совместимый бэкенд. jj использует Git-репозиторий как хранилище, работает с вашими .git/ и удалёнными репо. Коллегам ничего менять не надо.

Рабочая копия — это коммит. Нет отдельного staging area. Любое изменение файла сразу формирует новую версию коммита с тем же change ID.

Change ID ≠ commit ID. Change — это «идея изменения», commit — её конкретное воплощение. Описание и содержимое можно менять, change ID остаётся стабильной ссылкой.

Anonymous branches. Ветки не обязаны иметь имена: граф коммитов сам по себе задаёт структуру. Имена нужны только для push на GitHub.

First-class conflicts. Конфликты хранятся в истории как часть коммита, а не как маркеры в файле. Rebase не останавливается на конфликте — продолжается, и потомки автоматически перестраиваются, когда вы фиксите исходник.

Operation log и jj undo. Любая операция — в том числе rebase и abandon — откатывается одной командой. Потерять работу в jj сложнее, чем в Git.

Установка и первый репозиторий

jj написан на Rust. Самый простой способ — через cargo. На апрель 2026 актуальная версия — 0.40.x; учебник Клабника написан по 0.23.0, поэтому ниже в примерах показана именно она, чтобы совпадал вывод команд.

Альтернативы — Homebrew, пакеты для Linux, бинарники с страницы установки. После установки надо указать имя и почту:

Инициализация нового репозитория выглядит так:

Обратите внимание на jj git init, а не просто jj init. У jj есть собственный формат репозитория, но он пока экспериментальный. На практике все используют Git-бэкенд: изнутри это обычный .git/, который без проблем читает git log, IDE и CI-скрипты.

Рабочая копия — это коммит

Первое, что сбивает с толку git-пользователя: в jj нет «рабочей копии» и «индекса» как отдельных сущностей. Любое изменение файла сразу становится частью текущего коммита (помечается символом @).

Посмотрим статус свежего репо:

Даже пустой репозиторий уже содержит коммит yyrsmnoo. У него два идентификатора:

• Change ID (yyrsmnoo) — стабильный идентификатор «идеи изменения». Это не hex, а короткая случайная строка из букв — jj специально выбирает алфавит так, чтобы ID читались и набирались проще, чем git-хеши.
• Commit ID (e7cfc43b) — конкретная реализация: набор файлов + описание.

Это центральная концепция. Когда вы редактируете файл или меняете описание — commit ID обновляется, а change ID остаётся прежним. Change ID — это как будто номер задачи в трекере: ссылка на идею, не на конкретный снимок.

Основной цикл: describe → work → new

В Git вы сначала пишете код, потом коммитите с сообщением. В jj — наоборот: сначала описываете, что собираетесь сделать, потом работаете.

Без флага -m откроется редактор. Описание можно менять в любой момент и сколько угодно раз — change ID не поменяется, но commit ID обновится. Это удобно: пишете начальное описание, уточняете по мере работы.

Когда изменение готово, создаём следующее поверх него:

Всё. Коммит сформирован, можно продолжать работать в новой пустой рабочей копии. Никаких git add, git commit и git status перед коммитом не нужно. jj сам отслеживает, какие файлы поменялись.

Иногда в jj всё ощущается так же, как в git, но наоборот. В git мы завершаем работу коммитом. В jj мы начинаем работу, создавая change, а потом правим код. Гораздо полезнее сначала написать, что ты собираешься сделать, и уточнять по ходу, чем придумывать commit message постфактум.

Squash vs Edit: два рабочих процесса

У jj-сообщества сложились два устойчивых паттерна. Squash — любимый у Мартина, создателя jj. Edit — у тех, кому squash не зашёл.

Squash workflow

Аналог Git-индекса: у нас есть «главный» коммит с описанием работы, а поверх — пустой change, в который сыплются все текущие правки. По готовности части работы переносим изменения в основной коммит командой jj squash.

1. jj new -m "feat: CSV parser" — создаём коммит с описанием работы.
2. jj new — поверх него создаём пустой коммит, в котором идёт работа.
3. Редактируем файлы. Всё попадает в текущий change (@).
4. jj squash -i — интерактивно выбираем, какие куски из @ переехать в родительский change. Это как git add -p, только работает и задним числом.

Edit workflow

Противоположный подход: редактируем существующие коммиты напрямую. Создаём цепочку пустых коммитов с описаниями будущих кусочков работы, а потом командой jj edit <change-id> переключаемся между ними и дописываем содержимое. jj автоматически перестраивает потомков при каждом изменении.

Это встроенный interactive rebase без отдельной «фазы rebase»: вы просто редактируете средние коммиты истории, как если бы они были текущими. Ни тодо-файлов, ни «continue/abort» — всё делается обычными командами.

Анонимные ветки и revsets

Одно из самых непривычных для git-пользователя решений: ветки в jj не обязаны иметь имена. Вы можете начать эксперимент с новой идеей, не придумывая ничего вроде feature/experimental-cache-v2: если у двух коммитов один родитель — это уже ветвление, и для jj этого достаточно.

В Git всё, что не находится на именованной ветке, считается мусором и рано или поздно удаляется сборщиком («detached HEAD»). В jj мусора в этом смысле не бывает — все изменения равноправны, пока вы явно не сделаете jj abandon.

Имена в jj нужны только для push в Git-репозитории (GitHub, GitLab, etc.). Внутри Meta, где используют похожий VCS, по словам Стива, «почти никто не заморачивается именами веток, когда привыкает».

Revsets: язык запросов к истории

Чтобы ссылаться на конкретные коммиты без имён, в jj есть revsets — DSL для запросов к графу истории. Примеры:

• @ — текущий change.
• @- — родитель текущего change.
• @+ — все прямые потомки.
• trunk()..@ — всё, что было после ветвления от основной ветки (удобно смотреть свою работу).
• description(bug) — все коммиты, где в описании есть слово «bug».
• author("steve") — все коммиты Стива.
• heads(all()) — все «концы» ветвлений в репозитории.

Revsets комбинируются операторами: & (пересечение), | (объединение), ~ (отрицание). Практический сценарий: нужно найти, где сломался тест, — пишете jj log -r "description(bug) & author(me)", получаете список своих баг-фиксов. В Git для такого каждый пишет свой скрипт поверх git log --grep --author.

First-class конфликты: как jj хранит их в истории

Это нетривиальное архитектурное решение jj. В Git, если rebase упал на конфликт, процесс останавливается — вы фиксите файл, потом git rebase --continue, и так до конца цепочки. Если конфликт в середине, приходится разруливать его отдельно.

В jj конфликт — это нормальное состояние коммита. Он сохраняется в истории, не мешает дальнейшей работе, rebase идёт до конца и ничего не останавливает.

Что это даёт на практике:

1. Rebase никогда не застревает. Пересобираете 20 коммитов поверх нового main — получаете 20 коммитов, из которых помечены конфликтами только те, где реально столкнулись правки.
2. Конфликт можно отложить. Создали новую работу поверх конфликтного коммита — jj корректно протаскивает конфликт через все потомки.
3. Автоматический rebase потомков. Когда вы фиксите конфликт в @, все дочерние change автоматически перестраиваются — и, если их содержимое не пересекалось с конфликтным местом, они выходят из конфликтного состояния без ручного вмешательства.

Пример из учебника: есть конфликтный коммит, поверх него — ещё один change (тоже в конфликте из-за наследования). Исправляете файл в родителе — и jj пишет:

Потомок вышел из конфликта сам. В Git такое разруливают вручную или через git rerere (опциональная фича «Reuse Recorded Resolution», запоминающая решения конфликтов для повторного применения).

Operation log: почему в jj сложно потерять работу

Git хранит историю коммитов, но не историю операций. Если вы случайно сделали git reset --hard и коммит не попал в reflog (или reflog протух), он пропал. В jj иначе: каждая команда, меняющая состояние репо, пишется в operation log и хранится по умолчанию 30 дней.

Любую операцию откатывает jj undo. В отличие от git reflog, который показывает только движения HEAD, jj лог — это полный журнал изменений репозитория, и любая точка в нём — валидное состояние, к которому можно откатиться.

Случайно сделали jj abandon на важном change? jj undo. Случайно перебазировали ветку не туда? jj undo. Хотите посмотреть, как репо выглядел час назад? jj op restore <op-id>.

Что это меняет на практике

Stacked diffs без боли

Stacked diffs — это практика, когда большую фичу разбивают на цепочку мелких PR, каждый поверх предыдущего. В Git это требует сторонних инструментов (graphite, git-branchless) или ручного жонглирования с --onto. В jj — естественный режим: каждый change в цепочке — самостоятельный коммит, при изменении родителя все потомки перестраиваются автоматически. Для push на GitHub каждому коммиту цепочки достаётся имя через jj bookmark create.

Interactive rebase — просто редактирование

В Git git rebase -i — отдельный режим с тодо-файлом, в котором pick/squash/drop/reword. В jj это обычные команды: jj squash, jj abandon, jj describe <change>. Не нужен отдельный «режим rebase» — вы просто редактируете историю как данные.

Staging area уходит — и не жалко

Squash workflow воспроизводит поведение Git-индекса (отбор кусков правок), но делает это задним числом. Не нужно заранее решать, что попадёт в коммит — можно сначала написать код, потом через jj squash -i распределить куски по нужным change.

Выводы

jj — редкий случай, когда инструмент можно попробовать без риска: Git-бэкенд оставляет вам путь назад в любой момент, а новые концепции (change ID, first-class конфликты, op log) не требуют от команды ничего менять. Вы буквально можете работать с репозиторием через jj, пока коллега рядом пишет git commit.

Главная архитектурная ставка jj — перенести «операции с историей» из особых режимов (rebase, cherry-pick, reflog) в обычное редактирование графа коммитов. Если вы когда-либо путались в git rebase -i или теряли работу в git reset --hard — jj решает обе проблемы на уровне модели.

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

Оригинал — учебник Стива Клабника «Steve's Jujutsu Tutorial». В полной версии — ещё главы про named branches, работу с GitHub, кастомизацию templating-движка и продвинутые workflow (workspaces, colocated repositories). Документация проекта — jj-vcs.github.io/jj.

Если хочется попробовать — возьмите любой свой Git-репозиторий и выполните jj git init --colocate. Флаг --colocate создаёт jj-репозиторий рядом с существующим .git/, не трогая историю: можно параллельно работать обоими CLI. Дальше — jj log и по учебнику.

Это перевод статьи Грега Пеховски, консультанта по аудиту кодовых баз. Его подход — диагностика проекта через историю коммитов, прежде чем читать хоть одну строку кода.

• Файлы с наибольшим churn (частотой изменений) — главные кандидаты на рефакторинг и источник багов
• Один человек с 60%+ коммитов — bus factor, а если он ушёл полгода назад — это кризис
• Пересечение churn-файлов и баг-файлов даёт точную карту самого рискованного кода
• Количество коммитов по месяцам показывает, растёт проект или теряет команду
• Частые revert и hotfix — сигнал проблем с CI/CD и тестированием

Что меняется чаще всего

20 самых часто изменяемых файлов за последний год. Файл на первом месте — почти всегда тот, про который предупреждают: «А, этот файл. Его все боятся трогать».

Высокий churn (частота изменений) сам по себе не проблема — иногда это просто активная разработка. Но высокий churn у файла, за который никто не хочет отвечать — самый чёткий сигнал «тормозящего» кода. Это файл, где каждое изменение — патч на патч, а последствия мелкой правки непредсказуемы.

Исследование Microsoft Research 2005 года показало, что метрики на основе churn предсказывают дефекты надёжнее, чем метрики сложности кода. Автор рекомендует взять топ-5 файлов из этого списка и сверить их со списком баг-хотспотов (команда ниже). Файл, который одновременно high-churn и high-bug — главный риск проекта.

Кто это написал

Все контрибьюторы, отсортированные по числу коммитов. Если один человек — автор 60% и более коммитов, это bus factor. Если он ушёл полгода назад — это кризис.

Проверьте, кто активен за последние полгода:

Если топ-контрибьютор за всё время не появляется в полугодовом окне — это красный флаг, который стоит сразу обсудить с командой.

Смотрите и на «хвост» списка: 30 контрибьюторов всего, но только трое активны за последний год. Люди, которые строили систему — не те, кто её поддерживает.

Нюанс: если команда использует squash-merge, команда покажет того, кто мержил, а не того, кто писал код. Уточните стратегию мержа, прежде чем делать выводы.

Где скапливаются баги

Та же структура, что и команда churn, но отфильтрованная по коммитам с ключевыми словами багов. Сравните этот список с churn-хотспотами: файлы, попавшие в оба списка — самый рискованный код. Они постоянно ломаются и постоянно патчатся, но никогда не чинятся по-настоящему.

Качество результата зависит от дисциплины коммит-сообщений. Если команда пишет «update stuff» на каждый коммит — ничего полезного не получите. Но даже грубая карта плотности багов лучше, чем никакой карты.

Проект растёт или умирает

Количество коммитов по месяцам за всю историю репозитория. Ищите паттерны:

• Ровный ритм — здоровый проект
• Резкое падение вдвое за месяц — обычно кто-то ушёл
• Нисходящая кривая за 6-12 месяцев — команда теряет темп
• Всплески с тишиной между ними — пакетные релизы вместо непрерывной поставки

Однажды я показал CTO график коммитов его команды. Он сказал: «Это когда мы потеряли второго senior-инженера». Раньше он не связывал эти события. Это данные о команде, не о коде.

Как часто команда тушит пожары

Частота revert и hotfix. Несколько за год — норма. Откаты каждые пару недель — команда не доверяет своему деплой-процессу. Это симптом глубже: ненадёжные тесты, отсутствие staging или пайплайн, в котором откат сложнее, чем должен быть.

Нулевой результат тоже сигнал: либо команда действительно стабильна, либо никто не пишет описательные коммит-сообщения.

Пять команд, пара минут. Они не расскажут всё, но покажут, какой код читать первым и что искать. Разница между методичным погружением в кодовую базу и бесцельным блужданием по файлам.

Оригинал: Git commands I run before reading any code, Грег Пеховски.

— add / commit / push — три команды, покрывающие 80% ежедневной работы; остальное — ветвление и merge.

— Rebase линеаризует историю, merge сохраняет — выбор зависит от workflow команды, не от личных предпочтений.

— Git hooks позволяют автоматизировать проверки локально, до push — без настройки CI/CD.

— GitHub, GitLab, Bitbucket — платформы вокруг Git; сам Git работает локально и не зависит ни от одной из них.

— Reflog хранит историю HEAD 30–90 дней — даже «потерянный» после reset коммит можно восстановить.

Что такое Git и зачем он нужен

В 2005 году Линус Торвальдс создал Git для управления исходным кодом ядра Linux. До этого команда использовала проприетарную систему BitKeeper, но после конфликта с её владельцами Торвальдс написал собственную VCS за две недели. Главные требования: скорость, поддержка нелинейной разработки (тысячи параллельных веток) и полная распределённость.

В отличие от централизованных систем вроде SVN или CVS, где есть единственный сервер с полной историей, Git даёт каждому разработчику полную копию репозитория — со всей историей коммитов, ветками и тегами. Это означает, что вы можете работать офлайн, создавать ветки мгновенно и не зависеть от доступности сервера. Mercurial — ещё одна распределённая VCS — решал те же проблемы, но Git победил благодаря скорости, гибкости ветвления и экосистеме GitHub.

Главное преимущество распределённой модели — отказоустойчивость и скорость. Все операции, кроме push/pull, выполняются локально: создание ветки, коммит, просмотр истории, diff — всё работает мгновенно без сетевого подключения. Если центральный сервер упадёт, любой клон — полная резервная копия. В централизованных системах потеря сервера означает потерю всей истории.

Сегодня Git используют более 95% разработчиков по данным Stack Overflow Developer Survey. Но Git — это только инструмент контроля версий, а не платформа для совместной работы. GitHub, GitLab и Bitbucket — это платформы, построенные вокруг Git. Подробнее о том, в чём разница между Git и GitHub, читайте в отдельной статье.

Установка, настройка и первый репозиторий

Git доступен на всех основных платформах. На macOS проще всего установить через Homebrew: brew install git. На Linux — через пакетный менеджер: sudo apt install git (Ubuntu/Debian) или sudo dnf install git (Fedora). На Windows — через официальный установщик с git-scm.com или менеджер пакетов: choco install git. Подробный разбор всех шагов — от установки до первых команд.

После установки убедитесь, что Git доступен, командой git --version — она выведет текущую версию и подтвердит, что всё работает.

После установки первым делом настройте имя и email — они будут записаны в каждый ваш коммит:

Теперь можно создать первый репозиторий. Команда git init превращает обычную папку в Git-репозиторий, создавая скрытую директорию .git со всей служебной информацией:

Файлы в Git проходят через три состояния: рабочая директория (working directory) — где вы редактируете файлы; область подготовки (staging area, она же index) — промежуточное хранилище для следующего коммита; репозиторий (.git) — постоянное хранилище всех коммитов. Понимание этого цикла — фундамент работы с Git.

Ещё несколько полезных настроек на старте: git config --global init.defaultBranch main — новые репозитории будут создаваться с веткой main вместо master. git config --global alias.st status — создаёт сокращение git st вместо полного git status. Алиасы экономят время при ежедневной работе: co для checkout, br для branch, lg для красивого лога.

Основные команды: add, commit, log, diff

Ежедневная работа с Git строится вокруг пяти команд. git add перемещает изменения в staging area. git commit фиксирует снимок. git status показывает текущее состояние. git log выводит историю. git diff показывает разницу между версиями. Если вы освоите только их — уже закроете 80% повседневных задач. Подробный быстрый старт по основным операциям собран в отдельном материале.

git add . добавляет все изменённые файлы разом, но аккуратнее добавлять конкретные файлы — так вы не затянете в коммит лишнее. Полезный вариант: git add -p — интерактивное добавление по частям (hunks), когда в одном файле несколько логически разных изменений.

Хороший коммит — атомарный: одно логическое изменение, понятное сообщение. Сообщение коммита состоит из заголовка (до 72 символов, отвечает на вопрос «что сделано») и опционального тела (через пустую строку, объясняет «почему»). Плохо: fix. Хорошо: fix: prevent crash when user has no avatar. Привычка писать осмысленные коммиты окупается при поиске багов через git log и git bisect.

Файл .gitignore определяет, какие файлы Git должен игнорировать: зависимости (node_modules/), артефакты сборки (dist/), секреты (.env). Без правильного .gitignore репозиторий быстро засоряется бинарниками и конфигурациями IDE. У нас есть полный гайд по .gitignore с готовыми шаблонами для Python, Node.js и Java. А для быстрой справки — шпаргалки по Git-командам на каждый день.

Команда git diff — главный инструмент для просмотра изменений. Без аргументов она показывает unstaged-изменения рабочей директории. git diff --cached (синоним --staged) — изменения, добавленные в индекс. Сравнение между ветками: git diff main feature/auth. Между конкретными коммитами: git diff a1b2c3d e4f5g6h. Добавьте --stat для краткой сводки по файлам.

Ветвление и слияние

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

Git выполняет слияние двумя способами. Fast-forward merge происходит, когда целевая ветка является прямым предком исходной — то есть линейная история не расходилась — Git просто перемещает указатель вперёд. 3-way merge (трёхстороннее слияние) используется, когда обе ветки содержат новые коммиты — Git находит общего предка и создаёт merge-коммит с двумя родителями.

Конфликты слияния возникают, когда обе ветки изменили одни и те же строки одного файла. Git помечает конфликтные участки маркерами <<<<<<<, =======, >>>>>>>. Вам нужно выбрать нужную версию (или объединить обе), удалить маркеры и закоммитить результат. Современные IDE вроде VS Code и IntelliJ имеют визуальные инструменты для разрешения конфликтов — используйте их вместо ручного редактирования.

Чтобы минимизировать конфликты, регулярно подтягивайте изменения из основной ветки в свою feature-ветку: git merge main или git rebase main. Чем дольше ветка живёт изолированно, тем больше конфликтов при слиянии. Оптимальная длительность feature-ветки — от нескольких часов до пары дней.

Ненужную ветку удаляют командой git branch -d feature/auth (флаг -D — принудительное удаление, даже если ветка не слита). Переименование — git branch -m old-name new-name. Чтобы обновить remote, удалите старую ветку и запушьте новую: git push origin --delete old-name && git push -u origin new-name.

Для практики ветвления рекомендуем интерактивный тренажёр Learn Git Branching — он визуализирует дерево коммитов и помогает понять, как работают merge, rebase и cherry-pick.

Удалённая работа: remote, push, pull, fetch

Локальный репозиторий — это полная копия проекта, но для командной работы нужен remote — удалённый репозиторий на сервере (GitHub, GitLab, свой сервер). Команда git clone создаёт локальную копию удалённого репозитория и автоматически настраивает remote с именем origin.

Важно понимать разницу между git pull и git fetch. fetch скачивает новые коммиты с сервера, но не изменяет вашу рабочую ветку — вы можете спокойно посмотреть, что изменилось, через git log origin/main. pull — это fetch + merge в одну команду: скачивает и сразу сливает. Подробный разбор — разница между pull и fetch.

При командной работе вы часто столкнётесь с tracking-ветками. Когда вы делаете git push -u origin feature/auth, флаг -u связывает локальную ветку с удалённой. После этого достаточно писать просто git push и git pull без указания remote и ветки.

Совет: используйте git pull --rebase вместо обычного pull — так вы избежите лишних merge-коммитов при синхронизации с удалённой веткой. Это можно сделать поведением по умолчанию: git config --global pull.rebase true. Подходит не всем командам — если для вас важна полная история ветвлений (например, для аудита), оставьте обычный merge при pull.

Отмена изменений: revert, reset, stash

Ошибки в Git — не катастрофа. Система предлагает несколько инструментов для отмены изменений на разных этапах: от незакоммиченных правок до опубликованных коммитов. Разберём основные сценарии.

git revert — безопасная отмена. Создаёт новый коммит, который отменяет изменения указанного коммита. Не переписывает историю, подходит для публичных веток:

git reset — откат истории. Перемещает указатель ветки на указанный коммит. Три режима определяют, что происходит с файлами:

• --soft — коммит убирается, но изменения остаются в staging area. Удобно, если хотите переделать коммит.
• --mixed (по умолчанию) — коммит убирается, изменения остаются в рабочей директории, но не в staging.
• --hard — коммит убирается, все изменения удаляются. Осторожно: это необратимо для незакоммиченных правок.

git stash — временное хранилище. Прячет незакоммиченные изменения, чтобы переключиться на другую задачу, и позволяет вернуть их позже. Подробнее — как сохранить незакоммиченные изменения.

О detached HEAD стоит знать отдельно. Это состояние, когда HEAD указывает не на ветку, а на конкретный коммит. Любые новые коммиты в этом состоянии не принадлежат ни одной ветке и будут потеряны при переключении. Решение: создайте ветку командой git switch -c branch-name. Ещё больше сценариев разобрано в статье про типичные ошибки и как их исправить, а практические приёмы — в материале про Git-команды для исправления ошибок. Детальное сравнение инструментов отката — reset, revert и checkout на практике.

Rebase, cherry-pick и переписывание истории

git rebase переносит цепочку коммитов на новую базу. Вместо merge-коммита вы получаете линейную историю — как будто ваши изменения были сделаны поверх последней версии основной ветки. Это делает историю чище и проще для чтения.

Interactive rebase (git rebase -i) — мощный инструмент для «причёсывания» истории перед публикацией. Вы можете склеить несколько коммитов в один (squash), переформулировать сообщения (reword), удалить коммиты (drop) или изменить их порядок.

Золотое правило: никогда не ребейсите ветки, которые уже запушены и используются другими разработчиками. Rebase переписывает хеши коммитов, и у коллег возникнут конфликты при следующем pull. Rebase — для локальных, ещё не опубликованных коммитов.

git cherry-pick копирует конкретный коммит из одной ветки в другую. Полезно, когда нужно перенести один багфикс без слияния всей ветки:

git reflog — «чёрный ящик» Git. Хранит историю перемещений HEAD: 90 дней для достижимых коммитов и 30 дней для недостижимых (после reset или rebase). Даже «потерянный» коммит можно найти через reflog и восстановить — но не тяните дольше месяца. Больше о cherry-pick и других полезных командах — в статье cherry-pick и другие полезные команды. О выборе между rebase и merge — отдельный разбор: когда rebase, а когда merge.

Для массового переписывания истории используют git filter-branch или его современную замену — git filter-repo (устанавливается отдельно через pip install git-filter-repo). Типичные сценарии: удалить случайно закоммиченный пароль, сменить email автора во всех коммитах, вырезать крупный бинарный файл из истории. После переписывания истории потребуется git push --force. Безопаснее использовать git push --force-with-lease — эта команда отвергнет push, если remote-ветка обновилась после вашего последнего fetch, защищая от случайной перезаписи чужих коммитов.

Теги, релизы и версионирование

Теги — это именованные указатели на конкретные коммиты, обычно используемые для маркировки релизов. В Git есть два типа тегов: lightweight (просто указатель, как закладка) и annotated (полноценный объект с автором, датой и сообщением). Для релизов всегда используйте аннотированные теги:

Стандартная схема версионирования — Semantic Versioning (SemVer): MAJOR.MINOR.PATCH. MAJOR увеличивается при несовместимых изменениях API, MINOR — при новой функциональности с обратной совместимостью, PATCH — при багфиксах. Например, v2.1.3 означает вторую мажорную версию, первое минорное обновление и третий патч.

На GitHub теги автоматически превращаются в Releases — страницы с описанием изменений, бинарными файлами для скачивания и автоматически сгенерированными release notes на основе коммитов. Вы можете привязать к релизу скомпилированные бинарники, архивы, Docker-образы — всё, что нужно пользователям для установки конкретной версии.

Полезная практика — автоматизировать создание релизов. Инструменты вроде semantic-release и release-please анализируют коммиты в формате Conventional Commits и автоматически определяют следующий номер версии, генерируют CHANGELOG и создают GitHub Release. Это убирает человеческий фактор из процесса версионирования.

Переключиться на тег можно командой git checkout v1.2.0 или git switch --detach v1.2.0 — вы окажетесь в состоянии detached HEAD. Чтобы начать работу от тега, создайте ветку: git checkout -b hotfix/v1.2.1 v1.2.0. Ещё одна полезная конвенция — файл CITATION.cff в корне репозитория: GitHub распознаёт его и показывает кнопку «Cite this repository», что важно для научных и open-source-проектов.

Git Hooks: автоматизация проверок

Git hooks — это скрипты, которые Git автоматически запускает при определённых событиях: перед коммитом, после push, при получении изменений. Они позволяют автоматизировать проверки качества кода без настройки CI/CD. Подробный разбор — автоматизация проверок с Git hooks.

Основные клиентские хуки:

• pre-commit — запускается перед коммитом. Типичное использование: линтинг, форматирование, проверка секретов.
• commit-msg — проверяет сообщение коммита. Например, соответствие формату Conventional Commits.
• pre-push — запускается перед push. Можно прогнать тесты, чтобы не отправлять сломанный код.

Серверные хуки (pre-receive, post-receive) выполняются на стороне сервера и контролируют, какие push-запросы принимать. Они используются для enforce-политик: запрет force push в main, обязательные code review и т.д.

Среди менее известных, но полезных хуков: post-checkout — срабатывает после git checkout или git switch и удобен для автоматической переустановки зависимостей при переключении веток (например, npm install если изменился package-lock.json). post-update — серверный хук, выполняется после обновления refs; используется для отправки уведомлений или триггера деплоя.

Проблема хуков — они хранятся в .git/hooks/ и не попадают в репозиторий. Инструменты вроде Husky (JavaScript), pre-commit (Python) и Lefthook (Go, универсальный) решают эту проблему: хуки описываются в конфигурационном файле, который коммитится в репозиторий, и автоматически устанавливаются при npm install или аналогичной команде.

Продвинутые инструменты

За пределами ежедневных команд Git предлагает специализированные инструменты для нетривиальных задач. Знать их все не обязательно, но когда они нужны — они экономят часы работы.

git bisect

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

git worktree

git worktree позволяет иметь несколько рабочих директорий одного репозитория одновременно. Вместо git stash + переключения ветки вы можете открыть вторую ветку в отдельной папке и работать параллельно. Без флага -b команда работает только для уже существующей ветки:

git lfs

git lfs (Large File Storage) — расширение для работы с большими файлами (изображения, видео, модели ML). Вместо хранения бинарников в истории Git, LFS заменяет их указателями и хранит сами файлы на отдельном сервере. Без LFS репозиторий с бинарниками быстро разрастается до гигабайтов.

git submodule

git submodule — вложенные репозитории. Позволяют включить один Git-репозиторий в другой как зависимость с фиксированной версией. Полезно для монорепозиториев и shared-библиотек, но сложно в обслуживании — многие команды предпочитают альтернативы вроде пакетных менеджеров.

git blame и .gitattributes

git blame показывает, кто и когда изменил каждую строку файла. Незаменим для понимания контекста изменений — вместо вопроса «кто это написал?» вы сразу видите автора, дату и коммит. В IDE есть встроенные аналоги (Git Lens в VS Code, Annotate в IntelliJ). git format-patch и git apply позволяют экспортировать и импортировать изменения как файлы-патчи — полезно для передачи изменений без доступа к общему remote.

Файл .gitattributes управляет атрибутами путей в репозитории. Главное применение — нормализация переносов строк: строка * text=auto автоматически конвертирует CRLF в LF при коммите — критично для команд, где Windows- и Linux-разработчики работают над одним кодом. Также через .gitattributes отмечают бинарные файлы (*.png binary), выбирают алгоритм diff для конкретных типов (*.py diff=python) и настраивают стратегии merge.

Работа в команде: workflow и best practices

Git — гибкий инструмент, и без договорённостей в команде он быстро превращается в хаос. Workflow — это набор правил, определяющий, как команда работает с ветками, коммитами и релизами.

Git Flow, GitHub Flow и Trunk-Based

Три основных подхода — Git Flow, GitHub Flow и Trunk-Based Development:

• Git Flow — формальная модель с ветками develop, release, hotfix. Подходит для проектов с чётким циклом релизов (мобильные приложения, десктопный софт).
• GitHub Flow — упрощённый: main + feature-ветки + pull requests. Подходит для web-проектов с непрерывным деплоем.
• Trunk-Based Development — все работают в main, feature-ветки живут максимум 1–2 дня. Требует зрелой культуры CI/CD и feature flags.

Conventional Commits

Conventional Commits — формат сообщений коммитов, который структурирует историю и позволяет автоматически генерировать changelogs. Шаблон: type(scope): description. Основные типы: feat (новая фича), fix (багфикс), docs, refactor, test, chore.

Именование веток — ещё одна важная конвенция. Распространённая схема: type/description, например feature/user-auth, fix/login-crash, chore/update-deps. Если команда использует трекер — добавляйте номер задачи: feat/PROJ-123_user-auth.

Code review через pull requests — обязательная практика. PR (pull request) или MR (merge request в GitLab) — это предложение слить вашу ветку в основную. Коллеги проверяют код, оставляют комментарии, предлагают изменения. Хороший PR: небольшой и фокусированный, с описанием «зачем», скриншотами UI-изменений и ссылкой на задачу в трекере.

Защита веток (branch protection rules) — ещё один уровень безопасности. Можно запретить push напрямую в main, потребовать минимум один approve на PR, обязательное прохождение CI-пайплайна перед merge. Это предотвращает случайные поломки продакшена и формализует процесс доставки кода. Гит интегрируется в контекст DevOps — подробнее об этом в Git в контексте DevOps-инженерии.

Файл CONTRIBUTING.md в корне репозитория описывает правила контрибуции: как форкнуть проект, стиль кода, требования к тестам, оформление PR. GitHub автоматически показывает ссылку на него при создании issue и pull request. Весь текст в GitHub-экосистеме оформляется на Markdown — языке разметки с простым синтаксисом: заголовки, списки, блоки кода, таблицы, task lists (- [x] Готово), @mentions коллег. GitHub Flavored Markdown (GFM) расширяет стандартный Markdown автолинковкой URL, зачёркиванием и таблицами.

Платформы для хостинга Git-репозиториев

Все навыки Git из этой статьи работают с любой платформой — Git универсален, меняется только хостинг. Выбор платформы зависит от команды, юрисдикции и требований к инфраструктуре.

Облачные платформы

GitHub — крупнейшая платформа для хостинга Git-репозиториев с более чем 100 млн разработчиков. Основные инструменты: Pull Requests для code review, Issues для трекинга задач, Actions для CI/CD, Pages для статических сайтов и Copilot — ИИ-ассистент для написания кода. Регистрация бесплатна, для open-source используется Fork → PR workflow. Подробнее — как оформить профиль на GitHub.

GitLab — DevOps-платформа «всё в одном»: CI/CD, реестр контейнеров, мониторинг, управление проектами, Wiki. Доступна как облако и как self-hosted (Community Edition бесплатна). Особенно популярна в корпоративных окружениях, где нужна вся цепочка разработки в одном месте.

Bitbucket — платформа от Atlassian, тесно интегрированная с Jira и Confluence. Поддерживает Pipelines (CI/CD), Code Insights и branch permissions. Бесплатна для команд до 5 человек. Если команда уже работает в экосистеме Atlassian — Bitbucket будет естественным выбором.

GitVerse (gitverse.ru) — платформа от Сбера: хостинг репозиториев, CI/CD, code review. Подходит для команд, которым важна локальная юрисдикция хранения данных.

GitFlic (gitflic.ru) — Git-хостинг с приватными репозиториями и встроенным CI/CD. Поддерживает стандартный Git-workflow, есть бесплатный тарифный план.

Self-hosted решения

GitLab CE (Community Edition) — бесплатная версия GitLab, которую можно развернуть на собственном сервере, в Yandex Cloud, VK Cloud или любом другом облаке. Полный контроль над данными и инфраструктурой.

Gitea (gitea.com) — лёгкий open-source Git-сервер на Go. Быстрее и проще GitLab, подходит для небольших команд. Занимает минимум ресурсов и разворачивается за минуты.

Codeberg (codeberg.org) — некоммерческий хостинг на базе Gitea. Бесплатный и полностью открытый — подходит для open-source проектов и разработчиков, которые предпочитают некоммерческую инфраструктуру.

GitHub Actions и CI/CD

GitHub Actions — встроенная система CI/CD прямо в репозитории. Workflow описываются в YAML-файлах в директории .github/workflows/ и запускаются автоматически при определённых событиях.

Ключевые концепции GitHub Actions:

• Triggers — события, запускающие workflow: push, pull_request, schedule (cron), workflow_dispatch (ручной запуск)
• Runners — среда выполнения: GitHub-hosted (ubuntu-latest, windows-latest, macos-latest) или self-hosted для собственных серверов
• Secrets — зашифрованные переменные окружения, доступные через ${{ secrets.API_KEY }}. Хранятся в настройках репозитория
• Артефакты и кеш — сохранение результатов сборки между запусками и кеширование зависимостей для ускорения pipeline

Подробнее о CI/CD и смежных практиках — в нашем roadmap DevOps-инженера.

GitHub Pages, Copilot и другие инструменты

GitHub Pages — бесплатный хостинг статических сайтов прямо из репозитория. Поддерживает Jekyll из коробки, custom domains и автоматический SSL. Для привязки своего домена достаточно создать файл CNAME и настроить DNS.

GitHub Copilot — ИИ-ассистент, который подсказывает код прямо в IDE. Работает в VS Code, JetBrains, Neovim и других редакторах.

Security — набор инструментов для безопасности: Dependabot автоматически обновляет зависимости и предупреждает об уязвимостях, code scanning и secret scanning ищут уязвимости и утёкшие секреты в коде.

GitHub CLI (gh) — работа с GitHub из терминала: создание PR, просмотр Issues, управление Actions. Packages — реестр пакетов (npm, Docker, Maven). Projects — встроенное управление задачами с Kanban-доской и таймлайном.

Git на собеседованиях

Git-вопросы встречаются на собеседованиях на позиции любого уровня — от junior до senior. Не потому что нужно знать все команды наизусть, а потому что Git отражает понимание процессов разработки. Вот типичные вопросы и на что обращают внимание:

• Rebase vs merge — когда что? Ожидают: merge для публичных веток (сохраняет историю), rebase для локальных feature-веток (чистая история). Золотое правило rebase.
• Reset vs revert — в чём разница? Ожидают: revert безопасен (новый коммит), reset переписывает историю. Reset --soft/--mixed/--hard.
• Что такое fast-forward merge? Ожидают: линейное перемещение указателя без merge-коммита, возможно когда ветка «впереди» без расхождений.
• Что такое detached HEAD? Ожидают: HEAD указывает на коммит, а не на ветку. Коммиты будут потеряны без создания ветки.
• Как работает cherry-pick? Ожидают: копирует один коммит в текущую ветку с новым хешем. Сценарии использования.
• Что такое stash и когда его использовать? Ожидают: временное хранилище незакоммиченных изменений. Сценарий — переключение контекста.

На senior-позициях вопросы глубже: как устроен Git изнутри (DAG, объекты: blob, tree, commit, tag), стратегии ветвления для микросервисов, как настроить защиту веток (branch protection rules), как организовать монорепозиторий. Могут попросить нарисовать дерево коммитов после серии операций merge/rebase/cherry-pick.

Как готовиться. Практикуйтесь на реальных проектах — создайте тестовый репозиторий и воспроизведите каждый сценарий: конфликт слияния, interactive rebase, bisect. Отработайте ответы на вопросы вслух — на собеседовании важна не только правильность, но и уверенность.

Куда двигаться дальше

Если вы только начинаете путь в Git — рекомендуем пошаговый курс как выучить Git с нуля, где разобран оптимальный порядок изучения. Для глубокого погружения — бесплатная книга Pro Git на русском языке, охватывающая всё от основ до внутреннего устройства Git.

Следующие направления для изучения: GitOps — управление инфраструктурой через Git-репозитории (ArgoCD, Flux), когда состояние кластера описано в Git и автоматически синхронизируется; CI/CD — автоматизация сборки, тестирования и деплоя (GitHub Actions, GitLab CI, Jenkins); монорепозитории — управление несколькими проектами в одном репозитории (Nx, Turborepo, Bazel).

Начните с трёх команд (add, commit, push), затем освойте ветвление и merge. Когда почувствуете уверенность — переходите к rebase и hooks. Каждая ссылка в этом путеводителе ведёт на детальный разбор с примерами кода.

Файл .gitignore — один из первых, который появляется в любом репозитории. Но многие добавляют его по привычке, не разбираясь в синтаксисе и не думая о глобальных настройках. В итоге в историю коммитов попадают .pyc-файлы, папки node_modules и секреты из .env.

В этом гайде разберём синтаксис .gitignore с примерами каждого паттерна, дадим готовые шаблоны для Python, Node.js, Java и Go, а также покажем, как исправить ситуацию, если файл уже попал в индекс. Статья рассчитана на тех, кто уже знаком с основами Git — если нужно освежить базу, начните с введения в Git.

— .gitignore поддерживает паттерны *, **, !, / и комментарии через #

— Готовые шаблоны для Python, Node.js, Java и Go закрывают 90% типичных случаев

— Глобальный ~/.gitignore_global избавляет от повторения в каждом проекте правил для IDE и ОС

— Если файл уже в индексе, git rm --cached убирает его без удаления с диска

— .gitkeep — хак для отслеживания пустых директорий

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Синтаксис .gitignore: разбираем каждый паттерн

Git читает .gitignore построчно. Пустые строки игнорируются, строки с # в начале — комментарии. Остальное — паттерны.

* — любое количество символов в имени файла (кроме /):

** — любое количество директорий (рекурсивно):

! — отмена предыдущего правила (исключение из исключений):

Важно: паттерн ! не работает, если родительская директория уже заигнорирована. Например, если в .gitignore есть строка build/, то правило !build/keep-me.txt не поможет — файл всё равно будет игнорироваться. Чтобы исключение сработало, нужно сначала разрешить саму директорию: !build/, а затем уже — конкретный файл.

/ в начале — привязка к корню репозитория:

/ в конце — игнорировать только директорию, не файл с таким же именем:

# — комментарий. Используйте для группировки правил:

Шаблон .gitignore для Python

Python генерирует .pyc-файлы и папки __pycache__ при каждом запуске. Виртуальные окружения (venv, .venv) и файлы с переменными окружения (.env) тоже не должны попадать в репозиторий.

Шаблон .gitignore для Node.js

Главная причина тяжёлых репозиториев на Node.js — папка node_modules, которую забыли добавить в .gitignore. Её размер легко достигает сотен мегабайт.

Шаблон .gitignore для Java

Java-проекты собираются Maven или Gradle — у каждого свои папки артефактов. Скомпилированные .class-файлы и .jar-архивы пересобираются при каждом билде и в репозитории не нужны.

Шаблон .gitignore для Go

Go компилирует проект в бинарник — его хранить в репозитории не нужно. Папка vendor/ содержит копии зависимостей: её включать или нет — зависит от политики команды. Если используете Go modules без vendor-режима, добавьте папку в .gitignore.

Глобальный .gitignore: один раз для всех проектов

Некоторые файлы мусорят в любом проекте — .DS_Store на macOS, Thumbs.db на Windows, файлы IDE вроде .idea/ или .vscode/. Дублировать эти правила в каждом репозитории неудобно. Для этого есть глобальный .gitignore.

Настройка через core.excludesFile:

Пример содержимого ~/.gitignore_global:

После настройки Git применяет глобальные правила автоматически во всех репозиториях на вашем компьютере — без изменения .gitignore проекта.

Ещё один способ локально игнорировать файлы — .git/info/exclude. Этот файл работает как .gitignore, но не коммитится в репозиторий и виден только вам. Удобно для временных файлов, специфичных для вашего окружения, которые не стоит выносить в глобальный ~/.gitignore_global.

Файл уже в индексе: как перестать его отслеживать

Добавить правило в .gitignore недостаточно, если файл уже был закоммичен. Git продолжит его отслеживать. Нужно убрать файл из индекса, сохранив его на диске:

После этого добавьте правило в .gitignore и закоммитьте оба изменения — удаление из индекса и обновлённый .gitignore. Сам файл останется у вас на диске, но перестанет появляться в git status.

Если нужно очистить весь индекс и применить правила заново (например, после добавления нескольких паттернов):

Внимание: эта команда пересоздаёт индекс целиком. Не запускайте её при незакоммиченных изменениях.

.gitkeep: как отслеживать пустые директории

Git не отслеживает директории — только файлы. Если папка пустая, git add её просто проигнорирует. Это проблема, когда структура директорий важна для проекта: например, logs/, uploads/, tmp/.

Решение — добавить в пустую папку файл-заглушку .gitkeep:

Файл .gitkeep — неофициальное соглашение. Никакой специальной поддержки в Git нет, это просто пустой файл с понятным именем. Некоторые команды используют .githold или .keep — принципиальной разницы нет.

Инструменты: генераторы готовых шаблонов

Не обязательно писать .gitignore с нуля — есть готовые инструменты:

• gitignore.io (toptal.com/developers/gitignore) — генератор по языку, IDE и ОС. Введите «Python», «JetBrains», «macOS» — получите готовый файл.
• GitHub gitignore templates — официальная коллекция шаблонов от GitHub. Шаблоны для 150+ языков и фреймворков. Используется как основа при создании репозитория через интерфейс GitHub.
• gh repo create — при создании репозитория через GitHub CLI можно сразу выбрать шаблон .gitignore флагом --gitignore.

Для проверки, почему конкретный файл игнорируется (или не игнорируется), используйте встроенную команду:

Итог

Правильный .gitignore — это не формальность, а часть культуры работы с репозиторием. Он защищает от утечки секретов, не даёт захламить историю коммитов и экономит время при клонировании. Начните с шаблона под ваш стек (используйте gitignore.io или GitHub-коллекцию), добавьте глобальный файл для настроек IDE, и у вас не будет проблем с лишними файлами в git status.

Если хотите разобраться с Git глубже — изучите полный путеводитель по Git на Tproger: там собраны все ключевые темы от основ до продвинутых техник.

Существует несколько устоявшихся подходов: Git Flow, GitHub Flow, Trunk-Based Development и GitLab Flow. У каждого свои сильные стороны и ограничения. Разберём, чем они отличаются и какой выбрать для вашей команды.

— Git Flow оправдан для продуктов с длинными релизными циклами (мобильные приложения, коробочное ПО).

— GitHub Flow — простой выбор для SaaS и веб-команд с CI/CD: одна ветка main + короткоживущие фичи.

— Trunk-Based Development максимизирует скорость деплоя, но требует зрелой инфраструктуры: feature flags, автотесты, быстрый CI.

— GitLab Flow — компромисс между Git Flow и Trunk-Based: environment-ветки без сложных release-веток.

— Начните с GitHub Flow и переходите на Trunk-Based по мере роста CI/CD-зрелости команды.

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Git Flow: строгая структура для долгих релизов

Git Flow — самый известный workflow, описанный Винсентом Дриссеном в 2010 году. Его основа — две постоянные ветки: main (всегда стабильна, только теги релизов) и develop (интеграционная ветка). Поверх них — три типа временных веток.

• feature/* — новые функции, ответвляются от develop, сливаются обратно
• release/* — подготовка релиза: только баг-фиксы, документация, версии; сливается в main и develop
• hotfix/* — срочные фиксы прямо из main; сливается и в main, и в develop

Когда оправдан: мобильная разработка (App Store review занимает дни), коробочное ПО с поддержкой нескольких версий, enterprise-продукты с квартальными релизными циклами. Команда знает: в main только то, что уже у пользователей.

Минусы: тяжёлый для SaaS с деплоем несколько раз в день — слишком много веток, слишком много merge'ей. Ветки живут долго, накапливают конфликты. Инструмент git flow упрощает работу, но не убирает сложность модели.

GitHub Flow: простота для непрерывной поставки

GitHub Flow появился как реакция на сложность Git Flow. Правило одно: main всегда готов к деплою, новые фичи — в короткоживущих ветках через PR.

• Создаёте ветку от main с понятным именем (fix/login-timeout, feat/dark-mode)
• Коммитите, открываете Pull Request — это точка обсуждения и code review
• После approve'а и прохождения CI — мёрж в main и деплой

Когда оправдан: SaaS-продукты, веб-сервисы, команды с настроенным CI/CD, где деплой происходит после каждого мёрж в main. Простота модели снижает когнитивную нагрузку: все знают один набор правил.

Ограничение: отсутствует встроенная концепция «релиза» и «staging». Если нужно поддерживать несколько версий одновременно — GitHub Flow не покрывает этот кейс без дополнительных договорённостей.

Trunk-Based Development: всё в main, feature flags в помощь

Trunk-Based Development (TBD) доводит идею короткоживущих веток до предела — разработчики интегрируют изменения напрямую в trunk несколько раз в день. Модель существует с 1990-х и вдохновила упрощённые подходы вроде GitHub Flow. Если используются ветки — они живут максимум 1–2 дня и сливаются без церемоний.

Незавершённый код скрывается за feature flags: функция есть в коде, но включается только для нужной аудитории. Это позволяет постоянно интегрировать изменения, не ломая прод. Системы вроде LaunchDarkly, Unleash или простейший конфиг-файл — стандартный инструментарий TBD-команд.

Когда оправдан: зрелые команды с высоким покрытием тестами, быстрым CI (< 10 минут), культурой маленьких атомарных коммитов. Google, Facebook, Amazon деплоят по этой модели тысячи раз в день. По данным DORA (State of DevOps 2018), элитные DevOps-команды деплоят в 46 раз чаще, чем команды с низкой зрелостью процессов.

Требования: без надёжного CI/CD, автотестов и feature flags TBD превращается в хаос. Не пробуйте этот подход, если CI занимает больше 20 минут или нет хорошего тестового покрытия — нет универсального порога, но без него TBD рискован.

GitLab Flow: среднее между двух крайностей

GitLab Flow решает главный пробел GitHub Flow — отсутствие environment-веток. Концепция: main — это то, что разработано; staging — что протестировано; production — что в проде.

Фичи разрабатываются в ветках, сливаются в main, затем промоутируются вниз по цепочке окружений. Подход близок к реальности большинства команд: есть staging для QA, есть production для пользователей.

Когда оправдан: команды, которым нужен staging/QA-процесс перед релизом, но сложность Git Flow избыточна. Хорошо сочетается с GitLab CI/CD и авто-деплоем по веткам.

Таблица сравнения

Как выбрать: практические рекомендации

Начните с GitHub Flow — это разумный дефолт для большинства команд. Простые правила, понятный процесс PR/review, легко объяснить новичку. Если вы только выстраиваете процессы — это ваш выбор.

Переходите на Trunk-Based Development, когда: CI стабильно проходит за < 10 минут, команда привыкла к маленьким коммитам, есть инфраструктура для feature flags. Не форсируйте переход — команды, прыгнувшие в TBD без готовности, возвращаются обратно через месяц.

Выбирайте Git Flow только если у вас длинные релизные циклы с обязательной сертификацией, поддержка нескольких мажорных версий одновременно (например, мобильное приложение с 1.x и 2.x у разных клиентов), или регуляторные требования к freeze-периодам.

Помните: workflow — это договорённость внутри команды. Лучший workflow — тот, который все понимают и соблюдают. Формализованный Git Flow, который никто не соблюдает, хуже неформального «коммитим в main аккуратно». Также полезно настроить Git hooks для автоматической проверки соблюдения правил — linting, тесты, формат коммит-сообщений.

Git workflow — не религия. GitHub Flow подходит большинству команд прямо сейчас: он прост, понятен и хорошо масштабируется с CI/CD. Trunk-Based Development — следующий уровень для команд, которые хотят деплоить несколько раз в день и готовы инвестировать в инфраструктуру. Git Flow остаётся правильным выбором там, где он исторически появился — в продуктах с длинными релизными циклами. Выбирайте инструмент под задачу, а не под моду.

В этой статье разберём клиентские и серверные хуки, напишем реальные bash-скрипты и сравним инструменты для управления хуками в команде: Husky, pre-commit framework и lefthook.

— Git hooks — скрипты в .git/hooks/, выполняемые при событиях Git (коммит, пуш, мерж)

— Клиентские хуки: pre-commit, commit-msg, pre-push и другие — запускаются на машине разработчика

— Серверные хуки: pre-receive, update, post-receive — контролируют пуши на сервере

— Husky, pre-commit framework и lefthook упрощают управление хуками в команде

— Хуки — это локальная автоматизация; CI/CD — серверная: они дополняют друг друга

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Что такое Git hooks

Git hooks — это скрипты, которые Git запускает автоматически при определённых событиях: перед созданием коммита, после пуша, при мерже. Они живут в директории .git/hooks/ вашего репозитория.

По умолчанию там лежат примеры с расширением .sample — они неактивны. Чтобы активировать хук, достаточно убрать расширение и сделать файл исполняемым:

Скрипт может быть написан на любом языке: bash, Python, Ruby, Node.js — лишь бы интерпретатор был доступен в системе. Хук завершается с кодом 0 — операция продолжается; с ненулевым — Git прерывает её.

Клиентские хуки

Клиентские хуки выполняются на машине разработчика. Они не копируются при клонировании репозитория — каждый разработчик настраивает их сам (или через инструменты вроде Husky).

• pre-commit — запускается до того, как Git создаст коммит. Здесь запускают линтеры, форматтеры, статический анализ. Если хук вернул ненулевой код — коммит не создаётся.
• prepare-commit-msg — запускается после создания сообщения коммита по умолчанию, но до его открытия в редакторе. Используется для автоматического добавления номера задачи из названия ветки.
• commit-msg — получает путь к файлу с сообщением коммита. Здесь проверяют, соответствует ли сообщение формату (например, Conventional Commits).
• post-commit — запускается после создания коммита. Используется для уведомлений; не влияет на сам коммит.
• pre-push — запускается перед git push. Здесь запускают тесты или запрещают пуш в защищённые ветки.
• post-checkout — вызывается после git checkout, git switch и git clone. Удобен для автоматической установки зависимостей после смены ветки.

Серверные хуки

Серверные хуки выполняются на стороне Git-сервера (GitLab, Gitea, собственный сервер). Они позволяют централизованно контролировать все пуши — независимо от настроек на машинах разработчиков.

• pre-receive — вызывается при получении пуша, до обновления веток. Может отклонить весь пуш целиком: проверяет права, политику коммитов, размер файлов.
• update — аналог pre-receive, но вызывается отдельно для каждой обновляемой ветки. Позволяет разрешить пуш в одни ветки и запретить в другие.
• post-receive — запускается после успешного пуша. Используется для уведомлений, триггеров деплоя, синхронизации с внешними системами.

Практические примеры

pre-commit: запуск линтера перед коммитом

Хук проверяет только те файлы, которые добавлены в индекс. Это ускоряет проверку в больших проектах:

commit-msg: проверка формата сообщения

Хук проверяет, соответствует ли сообщение коммита формату Conventional Commits (feat: ..., fix: ..., docs: ... и т. д.):

pre-push: запрет пуша в main/master

Хук предотвращает случайный прямой пуш в защищённые ветки:

Инструменты: Husky, pre-commit framework, lefthook

Проблема «голых» хуков в том, что .git/hooks/ не попадает в репозиторий. Каждый разработчик должен настраивать их вручную. Инструменты решают эту проблему — хуки версионируются вместе с кодом и устанавливаются автоматически.

Husky — самый популярный выбор для JavaScript-проектов. Хуки описываются в файлах директории .husky/ и устанавливаются через npm install. Интегрируется с lint-staged для запуска проверок только на изменённых файлах.

pre-commit framework — мощный инструмент для Python-проектов (и не только). Хуки описываются в .pre-commit-config.yaml. Поддерживает большую экосистему готовых хуков — для Python, Go, Terraform, Docker и других технологий.

Lefthook — быстрый инструмент на Go, работает в любом проекте независимо от языка. Конфигурация в lefthook.yml. Поддерживает параллельный запуск хуков, что заметно ускоряет проверку в монорепозиториях.

Краткое сравнение инструментов:

• Husky — лучший выбор для Node.js/фронтенд-проектов. Глубокая интеграция с npm-экосистемой.
• pre-commit framework — богатая экосистема готовых хуков, идеален для Python и мультиязычных проектов.
• lefthook — самый быстрый, не зависит от языка, хорошо работает в монорепозиториях с параллельными задачами.

Хуки и CI/CD: дополняют, а не заменяют

Git hooks и CI/CD решают одну задачу — автоматическую проверку кода — но на разных уровнях. Хуки работают локально, до отправки кода на сервер. Это быстрая первая линия обороны: разработчик получает обратную связь за секунды, не дожидаясь очереди в CI.

CI/CD — это серверная автоматизация: она запускается независимо от хуков и не может быть отключена разработчиком. CI выполняет более тяжёлые проверки: интеграционные тесты, сборку Docker-образов, деплой. О том, как выстроить полный пайплайн, читайте в roadmap DevOps-инженера.

Правило: хуки проверяют то, что можно проверить быстро (секунды) — линт, форматирование, формат сообщения. CI проверяет то, что требует инфраструктуры — тесты с базой данных, e2e, performance benchmarks. Дублировать медленные проверки в хуках не стоит — разработчики будут обходить их через git commit --no-verify.

Git hooks — мощный инструмент, который превращает локальную разработку в управляемый процесс. Пять минут на настройку pre-commit и commit-msg экономят часы ревью в будущем. Начните с одного хука, убедитесь, что он не замедляет работу, и постепенно добавляйте остальные. Подробнее о том, как hooks вписываются в общий рабочий процесс с ветками и пулл-реквестами, читайте в статье про Git Flow, GitHub Flow и Trunk-Based разработку.

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

— git stash временно сохраняет незакоммиченные изменения и очищает рабочую директорию

— git stash pop применяет верхний stash и удаляет его; git stash apply применяет, но оставляет в стеке

— Флаг -u добавляет в stash неотслеживаемые файлы, флаг --keep-index оставляет staged-изменения нетронутыми

— При конфликте после pop stash не удаляется автоматически — нужно разрешить конфликты вручную

— git stash branch создаёт новую ветку прямо из stash — удобно для сложных случаев

Эта статья — часть нашего полного путеводителя по Git. Там — весь маршрут: от первого коммита до продвинутых workflow.

Что такое git stash и зачем он нужен

git stash сохраняет все изменения в рабочей директории (tracked-файлы) в специальный стек внутри репозитория и возвращает рабочую директорию к последнему коммиту. Это не коммит — изменения не попадают в историю. Это временная полка.

Stash хранится локально в .git/refs/stash и не отправляется при git push. Стек может содержать любое количество записей.

Именованные stash: git stash push -m

Без имени stash называется WIP on branch-name: hash message — не очень информативно. Флаг -m задаёт понятное описание:

Хорошее описание особенно важно, когда в стеке накапливается несколько записей. Через неделю «WIP on main: a3f2b1c» ничего не скажет — в отличие от конкретного сообщения.

Просмотр: list и show

Индексы в стеке работают как в массиве: stash@{0} — последний сохранённый, stash@{1} — предыдущий и так далее.

Применение и удаление: pop, apply, drop, clear

Ключевое различие между pop и apply: первый удаляет запись из стека после применения, второй — нет. Используй apply, если хочешь подстраховаться и оставить stash до полной проверки результата.

Включить untracked файлы: git stash -u

По умолчанию git stash сохраняет только отслеживаемые файлы (те, что уже есть в индексе). Новые файлы, которые ещё не добавлены через git add, остаются в рабочей директории.

Флаг -u (или --include-untracked) добавляет и их:

Сохранить только unstaged: git stash --keep-index

Иногда нужно убрать только рабочие (unstaged) изменения, оставив всё, что уже добавлено через git add. Флаг --keep-index делает именно это:

Удобно, когда готовишь коммит: добавил нужное в staged, а незакоммиченные черновики убрал временно — и коммитишь только то, что хотел.

Конфликты при pop: что делать

Если с момента сохранения stash основная ветка ушла вперёд и изменились те же строки, при git stash pop возникнут конфликты — точно так же, как при merge.

Важно: при конфликте pop не удаляет stash из стека автоматически. Это защита от потери данных — решай конфликты спокойно.

Если конфликты слишком сложные — лучше использовать git stash branch, о котором расскажем ниже.

Практический сценарий: hotfix без потери текущей работы

Классическая ситуация: ты разрабатываешь новую фичу, и приходит сообщение «упал прод, нужен срочный фикс». Вот как это решается с git stash:

Весь процесс занимает меньше минуты. Незакоммиченная работа сохранена, история не засорена недоделанными коммитами.

git stash branch: создать ветку из stash

Бывает, что изменений в stash накопилось так много, что применить их поверх текущей ветки без конфликтов не получится. Команда git stash branch решает это элегантно: она создаёт новую ветку с того коммита, где был сделан stash, и применяет его туда без конфликтов.

После успешного применения stash удаляется автоматически. Это лучший вариант, когда работа в stash выросла в самостоятельную задачу или когда конфликты неизбежны.

Если тебе нужно не просто отложить изменения, а откатить уже сделанные коммиты, читай как откатить коммит в Git — там разобраны git reset, git revert и когда что использовать.

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

— git revert создаёт новый коммит-отмену, безопасен после push в общую ветку

— git reset переносит указатель HEAD назад; бывает трёх видов: --soft, --mixed, --hard

— git restore / git checkout -- file отменяет изменения в рабочей директории или убирает файл из staging area

— Правило: если уже запушил — только revert; если локально — reset

git revert: безопасная отмена после push

git revert — самый безопасный способ отменить коммит. Он не переписывает историю, а создаёт новый коммит, который применяет обратные изменения. Именно поэтому revert подходит для публичных веток: коллеги, которые уже получили ваши изменения через pull, не столкнутся с конфликтами.

После выполнения команды Git откроет редактор для сообщения нового коммита — по умолчанию там будет что-то вроде Revert "Добавил новую фичу". Флаг --no-edit пропускает этот шаг и принимает сообщение автоматически.

Сценарий: вы запушили в main коммит с ошибкой, коллеги уже сделали pull. Использовать git reset здесь опасно — история разойдётся. Правильное решение: git revert HEAD и git push. Все получат отмену через обычный pull.

git reset: три режима работы

git reset перемещает указатель HEAD на указанный коммит, переписывая историю. Используйте только для локальных коммитов, которые ещё не запушены в общую ветку. Команда имеет три режима, которые отличаются тем, что происходит с индексом (staging area) и рабочей директорией.

• --soft — история откатывается, но все изменения остаются в индексе (готовы к коммиту)
• --mixed (по умолчанию) — история откатывается, изменения возвращаются в рабочую директорию, но из индекса убираются
• --hard — история откатывается, все изменения удаляются и из индекса, и из рабочей директории

Сравнение трёх режимов git reset:

• --soft: история изменяется, индекс сохраняется, рабочая директория сохраняется — применять, когда нужно переформулировать коммит или объединить несколько коммитов в один
• --mixed: история изменяется, индекс очищается, рабочая директория сохраняется — применять, когда нужно перевыбрать файлы для коммита
• --hard: история изменяется, индекс очищается, рабочая директория очищается — применять, когда нужно полностью выбросить изменения и вернуться к чистому состоянию

Практический пример: вы сделали три коммита с правками в одном файле и хотите отправить их как один. Используйте git reset --soft HEAD~3 — все три коммита исчезнут из истории, но изменения останутся в индексе. Остаётся сделать один финальный коммит.

git restore и git checkout: отмена изменений в файлах

Если нужно отменить изменения не в истории коммитов, а в конкретных файлах, используйте git restore (доступен с Git 2.23) или его предшественника git checkout -- file.

Сценарий: вы случайно добавили в git add файл с секретом .env. Перед коммитом выполните git restore --staged .env — файл останется на диске, но выйдет из индекса и не попадёт в коммит. Лучше сразу добавить его в .gitignore, чтобы не повторялось.

Если нужно вернуть файл к состоянию из определённого коммита, а не из HEAD, передайте хеш явно: git restore --source=a1b2c3d README.md. Это удобно, если файл менялся в нескольких коммитах и нужна конкретная версия.

Три сценария и как их решать

Сценарий 1: запушил не то в общую ветку. Уже сделали git push, коллеги могли получить изменения. Единственное безопасное решение — git revert HEAD и повторный push. Переписывать историю через reset здесь нельзя.

Сценарий 2: сломал рабочую ветку локальными коммитами. Изменения ещё не запушены. Используйте git reset --hard origin/main — ветка вернётся к состоянию на удалённом репозитории, все локальные коммиты и изменения исчезнут. Или git reset --mixed, если хотите сохранить файлы.

Сценарий 3: нужно убрать файл из последнего коммита. Коммит ещё локальный. Сначала отмените коммит: git reset --soft HEAD~1. Потом уберите файл из индекса: git restore --staged secret.txt. Затем сделайте новый коммит без этого файла.

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

Что выбрать: reset, revert или restore

Правило трёх вопросов, которое поможет выбрать инструмент:

• Изменения уже запушены в общую ветку? — только git revert
• Нужно отменить коммиты локально? — git reset (выберите режим по необходимости)
• Нужно отменить изменения в файлах (не коммиты)? — git restore

• git revert — создаёт новый коммит-отмену, не переписывает историю, безопасен после push; подходит для общих веток
• git reset — переносит HEAD назад, переписывает историю, только для локальных изменений; подходит для личных веток и правки последних коммитов
• git restore — отменяет изменения в файлах или убирает из staging, не трогает историю коммитов; подходит для отмены несохранённых изменений

Запомните простое правило: если коммит уже попал в общую ветку — только git revert. Если ещё локальный — можно использовать git reset с нужным флагом. А git restore — для быстрой отмены изменений в файлах до коммита. Эти три инструмента покрывают 95% ситуаций, с которыми сталкиваются разработчики в повседневной работе.

В этой статье разберём, как работает каждая команда, когда что применять и почему нарушение золотого правила rebase ведёт к конфликтам у коллег. Статья подойдёт разработчикам, которые уже знакомы с базовыми командами Git и хотят разобраться с ветвлением и историей коммитов.

— merge создаёт merge-коммит и сохраняет полную историю веток — когда и откуда пришли изменения.

— rebase переносит коммиты на новую базу и создаёт линейную историю без лишних merge-коммитов.

— Золотое правило: никогда не ребейсить публичные ветки, которые уже запушены и используются другими.

— feature-ветки перед слиянием — rebase; main/develop при получении чужих изменений — merge или pull --rebase.

— interactive rebase (git rebase -i) позволяет склеить, переименовать и отредактировать коммиты до публикации.

Также полезно изучить полезные команды Git — там собраны практические приёмы на каждый день.

Как работает git merge

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

Merge безопасен для публичных веток: он только добавляет новый коммит, не меняя существующие. Коллеги, которые уже склонировали репозиторий, без проблем сделают git pull и получат обновлённую историю.

Минус — при активной разработке история быстро засоряется merge-коммитами. Если в команде 10 человек и у каждого по несколько веток, граф становится нечитаемым.

Как работает git rebase

git rebase переносит коммиты текущей ветки на новую базу — то есть «перекладывает» их поверх другой ветки. При этом Git создаёт новые коммиты с теми же изменениями, но другими хешами. Результат — линейная история без лишних merge-коммитов.

Обратите внимание: D и E превращаются в D' и E' — это другие коммиты. Именно поэтому rebase опасен для ветки, которую уже видели другие разработчики: у них в локальных репозиториях останутся старые D и E, а в origin появятся новые D' и E'. При следующем git pull возникнет путаница и конфликты.

Interactive rebase: squash, fixup, reword

Флаг -i (interactive) открывает редактор со списком коммитов, которые можно переупорядочить и изменить перед публикацией. Это мощный инструмент для «уборки» истории feature-ветки до создания pull request.

Откроется список вида:

Команды, доступные в interactive rebase:

• squash (или s) — склеить коммит с предыдущим, объединить сообщения
• fixup (или f) — склеить с предыдущим, выбросить сообщение этого коммита
• reword (или r) — изменить только сообщение коммита
• edit (или e) — остановиться на коммите и внести изменения в файлы
• drop (или d) — удалить коммит

Типичный сценарий: перед созданием PR склеить несколько черновых коммитов («WIP», «ещё правки», «исправить тест») в один чистый коммит с понятным сообщением. Команда увидит осмысленную историю, а не рабочий дневник.

Когда что использовать

Нет универсального ответа — выбор зависит от контекста и договорённостей в команде. Вот практические ориентиры.

feature-ветка → используйте rebase

Если вы работаете над личной feature-веткой, которую ещё не публиковали (или публиковали, но работаете в одиночку), — обновляйтесь через rebase:

Так ваши коммиты окажутся поверх актуального main, и PR будет применяться чисто, без merge-коммита. История останется линейной.

Слияние в main → используйте merge

Когда feature-ветка проверена и одобрена, её сливают в основную ветку через merge. В большинстве команд это делается через pull request, и CI автоматически создаёт merge-коммит. Это нормально: merge-коммит в main фиксирует факт слияния и сохраняет связь с веткой.

Общая ветка → никогда rebase

Если над веткой работают несколько разработчиков, git rebase категорически нельзя использовать. Rebase переписывает хеши — и у коллег возникнет рассинхронизация. При следующем git pull Git увидит два «параллельных» набора коммитов с одинаковыми изменениями, и придётся вручную разбираться с конфликтами.

Золотое правило rebase

Никогда не делайте rebase ветки, которая уже запушена в удалённый репозиторий и используется другими разработчиками.

Это правило звучит просто, но регулярно нарушается. Сценарий: вы запушили feature-ветку, открыли PR, получили ревью — и решили «подчистить» историю через git rebase -i. После этого придётся делать git push --force. Если коллега уже склонировал вашу ветку — у него сломается история.

Исключение: git push --force-with-lease — более безопасная версия force push, которая откажет, если кто-то успел запушить в ту же ветку. Но лучше договориться в команде заранее: нужна ли вам линейная история или достаточно merge-коммитов.

Сравнение: merge vs rebase

• История: merge — нелинейная с merge-коммитами; rebase — линейная, как будто ветки не было
• Безопасность для команды: merge — всегда безопасен; rebase — только на локальных или личных ветках
• Трассировка: merge — видно, когда и откуда пришли изменения; rebase — история «переписана», оригинальные хеши утеряны
• Конфликты: merge — разрешаются один раз; rebase — могут появляться на каждом переносимом коммите
• Читаемость: merge — граф коммитов быстро загромождается; rebase — чистая линейная история
• Откат: merge — git revert по merge-коммиту; rebase — откатить сложнее, так как хеши изменились

Заключение

Выбор между merge и rebase — это не вопрос «что лучше», а вопрос «что нужно здесь». Merge сохраняет полную картину истории и безопасен для общих веток. Rebase даёт чистую линейную историю и идеален для подготовки feature-веток перед слиянием. Главное правило: не переписывайте то, что уже видели другие. Договоритесь о конвенции с командой — и придерживайтесь её.

Мне стало интересно: а можно ли на бесплатных мощностях, буквально "на коленке", собрать русскоязычного ИИ-рентгенолога? Спойлер: можно. В этой статье расскажу, как я скрестил Vision Transformer от Google с ruGPT-3 от Сбера, как боролся с датасетами на Kaggle и что из этого вышло. В конце — ссылки на GitHub и рабочее демо.

Архитектура: как пришить глаза к мозгу

Чтобы нейросеть могла посмотреть на снимок и написать текст, нужна архитектура Vision-Language Model. Обучать такого монстра с нуля у меня не было ни ресурсов, ни желания. Поэтому я пошел по пути Hugging Face VisionEncoderDecoderModel.

Идея проста как кирпич:

1. Энкодер (Глаза): Берем предобученный google/vit-base-patch16-224-in21k. Он отлично дробит картинку на патчи и извлекает визуальные фичи (понимает, где ребра, а где легкие).
2. Декодер (Язык): Берем ai-forever/rugpt3small_based_on_gpt2. У нее нет глаз, она умеет только генерировать текст.

Чтобы их сшить, пришлось немного "взломать" конфиг ruGPT-3, принудительно сказав ей: «Теперь ты декодер, и у тебя есть слои кросс-внимания» (is_decoder=True, add_cross_attention=True). Hugging Face заботливо создал новые пустые веса между двумя моделями. Именно эти связи мне и предстояло обучить.

Data Engineering: боль, страдания и Kaggle

Найти 7-10 тысяч рентгеновских снимков с подробными заключениями на русском языке в открытом доступе — задача нереальная.

Поэтому я взял открытый американский датасет Indiana University Chest X-Ray (IU X-Ray). Там есть картинки и тексты от американских врачей.

Прямо на Kaggle я поднял пайплайн машинного перевода на базе Helsinki-NLP/opus-mt-en-ru. Закинул тексты в GPU батчами по 32 штуки и за 10 минут перевел более 7000 медицинских заключений на вполне сносный русский медицинский язык.

Но тут платформа подкинула сюрприз: Kaggle прячет часть файлов в виртуальной файловой системе (снимков 7000, а стандартный скрипт видел только 4). Пришлось писать суровый маппинг с глубоким сканированием (os.walk), отрезать расширения и жестко связывать ID в CSV с реальными путями на диске.

Обучение: выжимаем все соки из бесплатных T4

Обучение проходило на Kaggle (2x NVIDIA T4). Чтобы модель не умерла от нехватки памяти (OOM), а сессия не отвалилась по тайм-ауту, пришлось шаманить:

• Включил Mixed Precision (fp16) — ускорило обучение в 2 раза.
• Настроил Gradient Accumulation — размер батча на видеокарту был всего 4, но виртуально мы накапливали до 16.
• Столкнулся с тем, что Seq2SeqTrainer крашится при попытке сохранить промежуточный чекпоинт мультимодального "франкенштейна". Решение? Выключить промежуточные сохранения (save_strategy="epoch") и молиться, чтобы Kaggle не завис. (Кстати, спасает JS-скрипт в консоли браузера, делающий клик раз в 60 секунд).

На 15 эпох ушло около 2.5 часов.

Что получилось в итоге? (Потрогать руками)

Получилась нейросеть, которая реально понимает, что изображено на рентгене, и сыпет терминами вроде «кальцифицированная гранулема» или «легочная васкулярность». Да, иногда она "галлюцинирует" (датасет в 7к снимков — это капля в море для ML), но базовые вещи вроде чистых легких или пневмоторакса сечет неплохо.

Я завернул модель в Gradio и выложил на Hugging Face Spaces. Можно зайти с телефона или ПК, загрузить любой снимок рентгена из гугла и посмотреть, что она выдаст.

👉 Потыкать лайв-демо тут: Hugging Face Space

👉 Весь код, пайплайны и веса тут: GitHub Репозиторий

Буду рад, если кому-то этот код сэкономит время при создании своих мультимодальных сеток. Залетайте в репу, ставьте звездочки, форкайте. Если есть идеи, как улучшить датасет (может, прогнать переводы через LLM для чистки медицинского сленга) — пишите в комменты!

(Дисклеймер: модель обучена в исследовательских целях за вечер. Не суйте ей свои снимки вместо похода к реальному врачу)

GitOps появился как ответ именно на эту проблему. Идея простая: желаемое состояние приложения и инфраструктуры хранится в Git, а специальный контроллер сам приводит кластер к этому состоянию. Разработчик не «деплоит руками» в Kubernetes, а меняет конфигурацию в репозитории, после чего система синхронизирует окружение с Git.

GitOps — это способ управлять конфигурацией и деплоем через Git, а не через ручные действия в кластере.

Он не заменяет CI/CD: CI собирает артефакт, а GitOps следит, чтобы среда реально пришла к состоянию из репозитория.

На практике GitOps чаще всего встречается в Kubernetes-связке с Argo CD или Flux CD, Helm и Kustomize.

Главная ценность GitOps — прозрачная история изменений, воспроизводимость и меньше ручных правок в production.

Если у команды ещё нет Docker, CI/CD, review-процесса и понятной структуры конфигурации, GitOps внедрять рано.

Если у вас ещё плавают базовые термины, лучше идти по цепочке: Git и GitHub, CI/CD, Kubernetes и Helm. Но если кластер у вас уже есть, а релизы всё ещё зависят от ручного kubectl, значит вы уже упёрлись в ту самую проблему, которую GitOps решает.

Что такое GitOps и зачем он нужен

GitOps — это способ управлять выкладкой и конфигурацией через Git. Манифесты, Helm values, Kustomize-оверлеи и другие декларативные описания лежат в репозитории, а изменения проходят через обычный процесс: commit, pull request, review и merge. После этого контроллер в кластере приводит среду к состоянию из Git.

Если говорить языком OpenGitOps и Argo CD, у вас есть desired state в Git и live state в кластере. Когда они расходятся, система показывает drift и может синхронизировать окружение обратно к версии, зафиксированной в репозитории.

• Git хранит не только код, но и манифесты, Helm chart-ы, Kustomize-конфигурации и параметры окружений.
• Изменения проходят через review и историю коммитов, а не через ручной доступ к production.
• Откат для декларативной конфигурации часто сводится к возврату предыдущего commit или merge request.
• Состояние среды становится проверяемым: то, что описано в репозитории, должно совпадать с тем, что реально запущено.

Если совсем коротко: CI/CD отвечает на вопрос «как собрать и доставить новую версию», а GitOps — на вопрос «как гарантировать, что среда реально живёт по описанию из Git».

Как работает GitOps на практике

Основная механика GitOps крутится вокруг трёх сущностей: репозиторий с желаемым состоянием, контроллер в кластере и цикл синхронизации. Разработчик меняет не сам кластер, а конфигурацию в Git. Контроллер читает репозиторий, сравнивает его с реальным состоянием и приводит окружение к нужной версии.

Git как источник истины

Проще всего думать так: Git хранит не “примерную конфигурацию”, а целевое описание среды. Если сервис должен работать с двумя репликами, конкретным образом и определёнными ingress-правилами, именно репозиторий считается источником этой правды.

Это не единственно правильная структура, но принцип один и тот же: production описан в Git, а не существует только в голове дежурного инженера или в shell history.

Контроллер и reconciliation loop

В кластере обычно работает GitOps-контроллер или стек контроллеров, например Argo CD или Flux CD. Он регулярно сравнивает репозиторий с текущим состоянием среды. Если что-то не совпадает, приложение помечается как рассинхронизированное, а дальше система либо показывает diff, либо сама подтягивает кластер к desired state из Git.

Почему это лучше ручного kubectl

Ручной деплой ломается не только из-за ошибок в YAML. Он ломается из-за неявности: непонятно, кто и когда поменял кластер, почему staging отличается от production и какой набор команд вообще был выполнен. GitOps убирает эту “устную традицию”: история изменений живёт в commit и pull request, а не в чьей-то памяти или shell history.

Самый понятный сценарий выглядит так: CI собрал образ api:1.4.2, команда поменяла тег в values-prod.yaml через pull request, после merge Argo CD подтянул новую конфигурацию в кластер. Если кто-то потом руками вернёт старый тег или изменит число реплик прямо в live-среде, контроллер увидит drift и покажет, что кластер разошёлся с Git.

Чем GitOps отличается от CI/CD

GitOps часто путают с CI/CD, потому что обе темы связаны с доставкой изменений. Но зона ответственности у них разная: CI/CD собирает и публикует артефакт, а GitOps отвечает за то, чтобы среда действительно пришла к конфигурации из Git.

• CI проверяет код: тесты, линтеры, сборка, статический анализ.
• CD публикует артефакт: image, package, release или deployment-пакет.
• GitOps управляет desired state среды: манифестами, Helm values, Kustomize-оверлеями и другими конфигурациями.
• В реальной цепочке они работают вместе: CI собрал образ, CD довёл его до registry, а GitOps синхронизировал кластер с новой конфигурацией из Git.

Поэтому фраза «GitOps заменяет CI/CD» некорректна. Типовой сценарий такой: CI собрал образ api:1.4.2, команда обновила тег в values-prod.yaml через pull request, после merge Argo CD увидел diff и применил новый релиз в кластер. Пока этот последний шаг живёт вне Git, у вас есть CI/CD, но нет управляемого desired state.

Какие инструменты чаще всего используют для GitOps

GitOps — это не конкретный продукт, а подход. Но в Kubernetes-мире есть несколько типовых инструментов, которые чаще всего закрывают эту задачу.

• Argo CD — удобный первый выбор, если нужен понятный UI, diff, sync-статусы и наглядная работа с приложениями в Kubernetes.
• Flux CD — GitOps-стек из нескольких контроллеров, который часто выбирают команды, предпочитающие максимально Git-centric и CRD-based подход.
• Helm — не GitOps-инструмент сам по себе, а упаковочный слой для релизов, с которым удобно работать GitOps-контроллеру.
• Kustomize — способ описывать вариации конфигурации без шаблонов; часто используется там, где команда хочет хранить разные окружения рядом, но без Helm chart-ов.

Для первого внедрения обычно не нужен сложный зоопарк инструментов. Достаточно одной понятной связки: например, Argo CD плюс Helm или Flux CD плюс Kustomize. Важнее не количество компонентов, а дисциплина: изменения в production идут только через Git.

Где GitOps особенно полезен, а где его рано внедрять

GitOps особенно хорошо раскрывается там, где уже есть несколько окружений, несколько сервисов и больше одного человека, который влияет на деплой. Как только конфигурация начинает жить отдельно от кода, а изменения попадают в кластер в обход review, GitOps перестаёт быть модным словом и становится способом вернуть контроль над средой.

• Уже пора: у вас есть Kubernetes, staging и production, несколько сервисов или несколько команд, а история изменений в кластере должна быть прозрачной.
• Уже пора: релизы регулярно упираются в ручной kubectl, чат-инструкции или правки values-файлов мимо pull request.
• Пока рано: если у вас ещё нет нормального контейнерного и CI/CD-фундамента.
• Пока рано: если команда пока не умеет поддерживать манифесты, Helm values и окружения в Git без хаоса и копипаста.

GitOps не чинит плохую инженерную дисциплину автоматически. Если в репозитории бардак, нет review, chart-ы размножены копированием, а secrets живут где попало, контроллер начнёт очень последовательно раскатывать этот бардак по окружениям.

Типичные ошибки при внедрении GitOps

1. Считать, что GitOps = Argo CD. Argo CD — только один из инструментов, а не весь подход целиком.
2. Пытаться внедрить GitOps до Docker, CI/CD и базовой дисциплины вокруг Git и review.
3. Хранить в Git хаотичную конфигурацию без структуры по окружениям, сервисам и зонам ответственности.
4. Смешивать сборку артефакта и управление состоянием среды в один непрозрачный pipeline.
5. Оставлять ручные hotfix-изменения в кластере без возврата их в репозиторий.
6. Думать, что GitOps отменяет мониторинг, rollback-план и нормальную эксплуатацию stateful-компонентов.

Хороший тест на зрелость простой: после инцидента вы открываете Git и видите, какая конфигурация должна быть в production. Потом возвращаете кластер к этому состоянию без ручной магии. Но важно помнить границу: GitOps хорошо откатывает декларативные ресурсы и desired state, а миграции базы, данные и внешние зависимости всё равно требуют отдельного плана.

С чего начать GitOps без лишней боли

Не надо сразу переводить на GitOps весь кластер и каждую сервисную мелочь. Нормальный старт — один сервис, одно непроизводственное окружение и очень понятный путь изменений.

1. Выберите один сервис или namespace и храните его манифесты, Helm values или Kustomize-конфигурацию в Git.
2. Подключите Argo CD или Flux CD и сначала добейтесь прозрачного diff и понятного sync-статуса, а не полной магии.
3. Зафиксируйте правило: изменения в production идут только через pull request, без ручных правок через kubectl.
4. Отдельно опишите rollback для миграций, данных и stateful-изменений: Git-rollback сам по себе не откатывает всё подряд.

Когда команда привыкнет к этой дисциплине на одном сервисе, можно переносить на GitOps другие окружения и приложения. Самый плохой сценарий — внедрять красивый термин, не меняя review-процесс, ownership и работу с конфигурацией.

Выводы

GitOps — это не магическая кнопка и не синоним CI/CD. Это способ сделать деплой и конфигурацию прозрачнее: изменения проходят через Git, состояние среды сравнивается с репозиторием, а drift, откаты и расследования становятся понятнее. Особенно хорошо это работает там, где Kubernetes уже есть, а цена ручных действий в production быстро растёт.

Если вам ещё рано, сначала доберите базу: Git и GitHub, Docker, CI/CD, Kubernetes и Helm. Если база уже есть и релизы всё ещё упираются в ручной доступ к кластеру, GitOps — логичный следующий шаг. А дальше уже можно разбираться с Argo CD и более сложными сценариями.

Для практики лучше держать рядом и официальные материалы: OpenGitOps, Argo CD и Flux CD. Они помогут не перепутать общий принцип с конкретной реализацией.

Пулл-реквесты задумывались как инструмент для совместной работы над кодом. На практике они превратились в бюрократическую процедуру: гигантские диффы, комментарии в разных вкладках, коллапсированные «outdated»-ветки обсуждений. Bernard Kolobara считает, что проблема не в самой идее code review, а в инструментах — и предлагает конкретные решения.

• Comprehension debt (долг понимания) — главная проблема, которую должен решать code review, а не только ловля багов
• Стековые пулл-реквесты: разбиение изменений на мелкие самодостаточные коммиты, которые ревьюятся независимо
• Приоритет файлов: тесты и зависимости показываются первыми в диффе через .gitattributes
• Всё на одной странице: код и обсуждение вместе, без вкладок
• ИИ не убил code review — он обнажил хрупкость инструментов, которые не справляются с растущим объёмом кода

Comprehension debt: долг понимания кода

Addy Osmani описал comprehension debt как разрыв между объёмом кода в проекте и тем, сколько из этого кода команда реально понимает. Чем больше разрыв — тем медленнее работа. Проектировать систему, которую полностью понимаешь, проще, чем ту, которую «примерно знаешь». С появлением ИИ-агентов в рабочих процессах этот разрыв значительно вырос.

Paul Graham в эссе о великой работе пишет, что лучшие идеи приходят вне клавиатуры — на прогулке, в душе, перед сном. Но для этого «фонового процессинга» нужно, чтобы контекст проекта уже был в голове. Сначала нужна осознанная работа с кодом.

Code review — идеальный момент для сокращения этого разрыва. Каждый ревью — возможность узнать, как кодовая база развивается, каковы её границы и ограничения. Не обязательно проверять каждую строку дифа — достаточно понять ключевые части, чтобы обновить ментальную модель. Ловля багов — лишь одна часть ценности ревью.

Как сократить разрыв: конкретные решения

Стековые пулл-реквесты

Разбить большой PR на маленькие — самый эффективный способ помочь ревьюеру. В теории для этого подходят коммиты: каждый — самодостаточная единица, рассказывающая историю. На практике это не работает из-за Git.

Git заточен под append-only workflow. Вернуться в старый коммит и отредактировать его — мучительно. Даже если вы аккуратно структурировали историю, рано или поздно появляется серия коммитов «fix», «actual fix», «ok now really fix». Когда смотришь на отдельный коммит, не видишь полной картины — правки могут быть размазаны по нескольким коммитам дальше по истории.

Bernard и его коллега Luísa решают эту проблему с помощью Jujutsu — VCS, которая позволяет прыгнуть в любой коммит и отредактировать его на месте, а затем автоматически пропагирует изменения через всю историю. Это позволяет «вылепить» идеальную историю коммитов.

В Lubeno стековые PR детектятся автоматически. Каждый PR показывается как дифф относительно родительского PR — ревью и одобрение идут независимо. Автор не ждёт, пока предыдущий PR смёржат, и может продолжать работу.

Приоритет файлов в диффе

При ревью автор первым делом смотрит тесты: были ли изменены существующие, тестируют ли новые что-то полезное. Затем — зависимости: добавляется ли новая и зачем. Но все платформы для code review показывают файлы в алфавитном порядке — важные изменения легко пропустить в большом диффе.

Lubeno использует кастомный атрибут priority в .gitattributes (это не стандартный атрибут Git, а расширение Lubeno):

Файлы с высоким приоритетом показываются первыми на странице PR. Простое решение, но оно гарантирует, что самые важные изменения вы увидите сразу.

Всё на одной странице

Почти все платформы для code review разносят комментарии, коммиты и код по разным вкладкам. Автор признаётся: «Я нажимал на вкладку Commits только по ошибке — ни разу намеренно». Обсуждение тесно связано с кодом, но чтобы следить за ним, приходится постоянно скроллить наверх, переключать вкладки и искать нужный фрагмент.

В Lubeno нет вкладок на странице PR. Код и обсуждение живут в одном месте.

Эволюция кода в рамках PR

PR — не статичная сущность. Это место для обсуждения и итераций. Знакомая ситуация: вы оставили комментарий, вернулись — и обнаружили несколько новых коммитов, а все ваши комментарии свёрнуты как «outdated». Непонятно, учтены ли ваши замечания, что изменилось с момента вашего последнего просмотра.

Lubeno отслеживает комментарии к коду и наложение interdiff (разницу между версиями файла в рамках PR): если код был изменён более поздним коммитом (или force push), разница видна прямо в контексте комментария. Не нужно переключаться между вкладками, чтобы понять, что произошло.

Будущее пулл-реквестов

Некоторые называют PR «реликтом прошлого» и призывают от них отказаться. Автор не согласен: процесс ревью кода сегодня ценнее, чем когда-либо. ИИ не убил code review — он обнажил хрупкость инструментов. Больше строк кода просто сделали их непригодными.

Code review находится в идеальной точке жизненного цикла: после всей творческой работы и прямо перед продакшном. Это последний шанс разобраться, что именно поедет к пользователям. Если вы хотите создавать продукт, который радует пользователей, вам нужно понимать, что происходит в коде.

Выводы

Статья Bernard Kolobara — не абстрактные размышления, а описание конкретных решений, реализованных в Lubeno. Даже если вы не планируете переходить с GitHub — идеи стековых PR, приоритета файлов и unified-страницы ревью стоит примерить к своему workflow.

Ключевой тезис: code review — не бюрократия, а инструмент обучения. Каждый ревью должен делать команду чуть умнее, а не просто ставить галочку.

Что такое Git

Git — это распределённая система контроля версий (Version Control System, VCS), которая отслеживает изменения в файлах и позволяет нескольким разработчикам работать над одним проектом одновременно. Git был создан Линусом Торвальдсом в 2005 году для разработки ядра Linux и сегодня является стандартом индустрии: по данным Stack Overflow Developer Survey, его используют около 93–95% профессиональных разработчиков. С помощью Git можно в любой момент вернуться к предыдущей версии кода, сравнить изменения и объединить работу нескольких людей с минимумом конфликтов — хотя конфликты при слиянии (merge conflicts) иногда возникают, Git помогает их разрешить.

- Git — бесплатная и открытая система контроля версий, созданная в 2005 году - Используется в более чем 93% профессиональных проектов по всему миру - GitHub — это облачный хостинг для Git-репозиториев, а не сам Git - Три состояния файла в Git: рабочая директория, staging area, репозиторий - Основные команды: git init, git add, git commit, git push, git pull - GitLab и Bitbucket — альтернативы GitHub с похожим функционалом - Первый коммит можно сделать за 5 минут после установки

Зачем нужна система контроля версий

Представьте: вы работаете над проектом и случайно удаляете важный файл или ломаете рабочий функционал. Без системы контроля версий восстановить данные практически невозможно. Именно для таких ситуаций и создавались VCS.

Вот основные задачи, которые решает Git:

• История изменений — вы видите, кто, когда и что изменил в коде
• Откат к предыдущей версии — если новый код сломал проект, достаточно одной команды
• Параллельная работа — несколько человек могут работать над разными частями проекта одновременно
• Эксперименты без риска — создайте отдельную ветку, попробуйте идею, и если не понравится — просто удалите ветку
• Резервное копирование — код хранится не только локально, но и в удалённом репозитории

Как работает Git

Git управляет файлами через три уровня. Понимание этой модели — ключ к тому, чтобы не путаться в командах и не терять изменения.

Рабочая директория (Working Directory)

Это обычная папка на вашем компьютере с файлами проекта. Здесь вы пишете и редактируете код. Git следит за изменениями, но пока не сохраняет их в историю — файлы просто находятся в состоянии «изменён» или «не отслеживается».

Staging Area (индекс)

Промежуточная зона, куда вы добавляете файлы перед сохранением. Думайте о ней как о корзине для покупок: вы выбираете нужные товары (изменения) и кладёте их туда, прежде чем оформить заказ (сделать коммит). Команда git add перемещает файлы в staging area.

Репозиторий и коммиты

Когда вы выполняете команду git commit, Git делает снимок всех файлов из staging area и сохраняет его в историю репозитория. Каждый коммит — это точка в истории проекта с уникальным идентификатором (SHA-хешем), автором, датой и сообщением. В любой момент можно вернуться к любому коммиту.

Ключевое отличие Git от большинства других VCS — распределённость. Каждый разработчик хранит полную копию репозитория со всей историей локально. Это означает, что можно работать офлайн и не зависеть от центрального сервера.

Основные команды Git

Большинство повседневных задач решается с помощью 7–10 команд. Разберём их по порядку.

git init — создать репозиторий

Инициализирует новый Git-репозиторий в текущей папке. После выполнения команды появится скрытая папка .git, в которой Git хранит всю историю. Папку .git удалять нельзя — в ней хранится вся история проекта.

git add и git status — добавить файлы в staging area

Команда git status показывает текущее состояние репозитория — какие файлы изменены, какие добавлены в staging area. Команда git add добавляет файлы в staging area.

git commit — сохранить изменения

Создаёт коммит из файлов, добавленных в staging area. Сообщение коммита должно кратко описывать, что именно изменилось. Хороший формат: глагол в повелительном наклонении + что сделано.

git push и git pull — синхронизация с удалённым репозиторием

Команда git push отправляет локальные коммиты на удалённый сервер (например, GitHub). Команда git pull загружает изменения с сервера и объединяет их с локальной версией.

git branch и git merge — ветки

Ветки — одна из самых мощных функций Git. Ветка — это независимая линия разработки. Вы можете создать ветку для новой функциональности, работать в ней, не затрагивая основной код, а потом объединить (merge) с главной веткой.

Что такое GitHub

GitHub — это облачная платформа для хостинга Git-репозиториев. Если Git — это инструмент на вашем компьютере, то GitHub — это место в интернете, где вы храните свой код и делитесь им с другими. Главная страница GitHub — github.com — основана в 2008 году и сегодня насчитывает более 100 миллионов разработчиков и свыше 420 миллионов репозиториев.

GitHub добавляет поверх Git множество удобных возможностей:

• Pull Request (PR) — предложение изменений с обсуждением кода перед слиянием
• Issues — система задач и багов прямо внутри репозитория
• Actions — автоматизация: тесты, деплой, сборка при каждом коммите
• GitHub Pages — бесплатный хостинг статических сайтов прямо из репозитория
• Discussions — форум для обсуждений внутри проекта
• Code Review — удобный интерфейс для ревью кода с комментариями к строкам

Git — это технология, а GitHub — это сервис поверх этой технологии. Можно использовать Git без GitHub (например, хранить репозиторий на собственном сервере), но нельзя использовать GitHub без Git.

Git vs GitHub vs GitLab vs Bitbucket

Разработчики часто путают эти понятия. Вот краткое сравнение четырёх основных инструментов экосистемы.

• Git — локальная система контроля версий, работает без интернета, устанавливается на компьютер
• GitHub — крупнейший хостинг для Git-репозиториев, принадлежит Microsoft с 2018 года, идеален для open-source
• GitLab — альтернатива GitHub с упором на DevOps, есть self-hosted версия, популярен в корпоративной среде
• Bitbucket — продукт Atlassian (Jira, Confluence), хорошо интегрируется с их экосистемой, популярен в командах

Для новичков рекомендуем начать с GitHub: он самый популярный, имеет лучшую документацию на русском языке и огромное сообщество. Бесплатный план включает неограниченное количество публичных и приватных репозиториев.

Как начать работать с Git: пошаговая инструкция

Следуйте этой инструкции, и через 10–15 минут у вас будет первый репозиторий на GitHub.

Шаг 1. Установка Git

• Windows: скачайте установщик с git-scm.com/download/win и запустите его
• macOS: откройте терминал и выполните brew install git (или xcode-select --install)
• Linux (Ubuntu/Debian): sudo apt install git

Шаг 2. Настройка имени и почты

Git подписывает каждый коммит вашим именем и почтой. Настройте их один раз — они будут использоваться во всех проектах.

Шаг 3. Создать аккаунт на GitHub

Перейдите на github.com, нажмите «Sign up» и заполните форму регистрации. Выберите бесплатный тарифный план — для начинающих он полностью достаточен.

Шаг 4. Создать первый репозиторий и сделать коммит

Выводы

Git — это не просто инструмент для разработчиков, это основа профессиональной работы с кодом. Без него невозможно представить ни командную разработку, ни open-source проекты, ни современный DevOps. Хорошая новость: базовые команды можно освоить за один вечер, а дальше — практика и опыт.

Что делать дальше:

1. Установите Git и создайте аккаунт на GitHub прямо сейчас
2. Сделайте первый репозиторий по инструкции из этой статьи
3. Попрактикуйтесь с ветками: создайте ветку, внесите изменения, слейте в main
4. Попробуйте сделать Pull Request в любой open-source проект — даже исправление опечатки в README считается
5. Изучите команды git stash, git cherry-pick и git bisect — они пригодятся на следующем уровне

Знание Git сегодня — обязательное требование для любого разработчика. Если вы только начинаете — это один из первых инструментов, который нужно освоить. Если уже работаете — углубляйтесь в продвинутые возможности: rebase, stash, cherry-pick, подмодули. Подробнее о всех возможностях можно прочитать в официальной документации Git.

Git лежит в основе всей современной DevOps-экосистемы. Следующий шаг — освоить Docker для контейнеризации приложений: именно связка Git + Docker образует фундамент любого CI/CD-пайплайна. А если хотите автоматизировать тестирование и доставку кода — читайте нашу статью о том, что такое CI/CD.

Если хотите собрать из Git, Docker, CI/CD, Kubernetes и Helm единый маршрут, посмотрите план обучения DevOps-инженера. Там видно, почему Git идёт первым и как из него вырастает вся следующая цепочка инструментов.

Шведский разработчик Торе Нестениус решил сорвать занавес. Он выпустил Coding Agent Explorer — открытый прокси-сервер, который в реальном времени показывает все общение между агентом и API Anthropic.

Сейчас поддерживается только Claude Code, но уже в таком виде инструмент дает неожиданно глубокое понимание того, как работает агентная разработка.

Что именно он показывает

Explorer перехватывает HTTP-запросы и визуализирует:

• системные промпты (часто намного длиннее, чем кажется);
• последовательность вызовов инструментов (Read, Grep, Write, Bash);
• шаги «размышления» агента;
• распределение задач между моделями (например, Haiku для рутинных операций и Sonnet/Opus для сложной логики);
• статистику токенов, включая кэш (cache_creation_tokens и cache_read_tokens).

По сути, инструмент можно воспринимать как «рентген для агентной разработки». Видно, какие файлы агент читает, как ищет паттерны в коде, почему он внезапно запускает тесты и сколько это стоит в токенах.

В интерфейсе два режима. HTTP Inspector — сухая таблица со всеми JSON-телами, временем ответа и расходом токенов. Conversation View — более «человеческий» режим, где процесс выглядит как диалог: шаги планирования, проверки гипотез, исправления ошибок.

Зачем это нужно

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

Когда агент «зависает», теперь можно увидеть, что он на самом деле делает: перебирает файлы, пересобирает контекст или тратит половину лимита токенов на анализ README.

А уже это помогает оптимизировать промпты и понимать реальную стоимость задач. В итоге ИИ перестает быть черным ящиком.

Безопасность и ограничения

Explorer работает только локально (localhost). API-ключи автоматически маскируются в интерфейсе.

Данные не сохраняются — все хранится в памяти и ограничено примерно тысячей запросов. Никаких внешних сервисов и баз данных.

По его словам, нейросеть сможет делать это даже эффективнее традиционных компиляторов.

Звучит громко. Но если разобрать тезис технически, все не так однозначно.

Что именно предлагает Маск

По словам миллиардера, вместо привычной цепочки «исходный код → компилятор → бинарник», ИИ будет получать задачу и сразу выдавать исполняемый файл. Без промежуточного слоя в виде читаемого кода.

Фактически это означает отказ от исходников как основного артефакта разработки. Промпт на входе, а .exe или ELF на выходе.

Почему это спорно с технической точки зрения

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

Один и тот же код при одинаковых условиях дает один и тот же бинарник.

LLM работают иначе: они генерируют вероятностный результат. Малейшая ошибка в бинарнике приведет к падению программы или трудноуловимому багу.

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

Кроме того, компиляция стоит дешево — это миллисекунды CPU. Генерация крупных бинарников через LLM потребовала бы миллионов токенов и значительно больших вычислительных затрат.

Где ИИ действительно меняет разработку

На фоне громких заявлений Маска, многие как будто забыли, что ИИ уже активно используется в программировании. Но в другом формате. Технология помогает писать исходный код, объяснять сложные участки, генерировать тесты, предлагать рефакторинг.

А дальше в дело все равно вступает компилятор — как проверяемый и предсказуемый этап.

Более реалистичный сценарий — улучшение компиляторов с помощью ИИ, а не их замена. Например, автоматический подбор оптимизаций или более агрессивная векторизация.

Об этом сообщил пользователь GitHub под ником Angry-Orangutan, опубликовав подробный баг-репорт в публичном репозитории Microsoft.

Проблема затрагивает новый режим agent / subagent в Copilot и связана не с безопасностью в классическом смысле, а с биллингом. Тем не менее, эффект от нее вполне материальный: дорогие модели вроде Claude Opus можно использовать бесплатно и сколько угодно долго.

Как работает обход биллинга

Механизм уязвимости строится на нескольких допущениях в архитектуре Copilot.

Во-первых, стоимость запроса рассчитывается только по первой модели, которая принимает сообщение. Во-вторых, запуск подагентов (subagents) и вызовы инструментов не учитываются как отдельные платные операции.

В результате пользователь может начать чат с «бесплатной» моделью, например GPT-5 Mini, а затем внутри нее создать подагента, явно указав для него уже премиум-модель.

Дальше все просто: бесплатная модель делегирует работу подагенту, а тот выполняет задачи с помощью Opus или другого дорогого ИИ — без списания лимитов. По словам автора отчета, таким способом он запускал сотни подагентов и часами обрабатывал файлы, потратив всего несколько платных кредитов.

Реакция Microsoft

Интересно, что изначально исследователь пытался передать проблему через MSRC — стандартный канал ответственного раскрытия уязвимостей. Однако там ответили, что «обход биллинга не относится к сфере безопасности» и предложили оформить баг публично.

В итоге issue действительно появилась в открытом репозитории VS Code, но довольно быстро была закрыта со статусом «not planned». Это означает, что компания не обещает что-либо исправить и уж тем более не комментирует сроки.

Это решение вызвало волну иронии в обсуждении: пользователи отметили, что Microsoft фактически оставила инструкцию по бесплатному использованию платных моделей в открытом доступе.

Почему это важно

Формально речь идет не о взломе, а о логической ошибке в расчете стоимости запросов. Но на практике уязвимость подрывает саму модель монетизации Copilot и агентных функций VS Code.

Линус Торвальдс закоммитил файл Project continuity — формальный план действий на случай, если он больше не сможет выполнять роль главного мейнтейнера проекта.

Переживать не стоит — пока что речи о скором уходе или передаче власти «наследнику» не идет. Документ скорее фиксирует то, как сообщество должно действовать в кризисной ситуации — внезапной и без предварительной подготовки.

Ранее подобные вопросы в Linux решались негласно и на уровне доверия, но теперь процесс впервые описан письменно.

Почему это вообще понадобилось

Linux — распределенный проект с сотнями мейнтейнеров, но финальная точка принятия решений по-прежнему сходится в одном месте: в основном репозитории ядра.

Исторически эту роль выполняет сам Торвальдс. Именно он принимает изменения в mainline и определяет, что считается «официальным» Linux.

В коммите напрямую упоминается релиз 4.19 в 2018 году — момент, когда Торвальдс временно отошел от проекта.

Тогда стало очевидно, что даже при развитой системе мейнтейнеров отсутствие одного человека создает управленческую неопределенность. Новый документ — попытка эту неопределенность устранить.

Как выглядит план преемственности

Если кратко, Linux не переходит под контроль одного нового лидера автоматически. Вместо этого запускается процесс коллективного управления.

Организатор последнего Linux Maintainers Summit обязан в течение 72 часов собрать обсуждение с участниками саммита и Technical Advisory Board (TAB) Linux Foundation.

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

Ключевая цель формулируется прямо в тексте — сохранить долгосрочное здоровье проекта и сообщества, а не просто «назначить замену».

Если саммит давно не проводился, состав участников определяет TAB. Через две недели после встречи, сообщество получает публичное разъяснение дальнейших шагов через официальную рассылку kernel.org.

Стартапы начали скупать Mac mini и использовать их не как персональные компьютеры, а как круглосуточных цифровых сотрудников. На этих машинах крутится Clawdbot — ИИ-ассистент, который берет на себя рутину и работает без выходных.

Mac mini как «железный сотрудник»

Компактный компьютер от Apple неожиданно оказался идеальным форматом для ИИ-работника.

Он тихий, энергоэффективный и может быть включен 24/7. В результате Mac mini стали использовать как отдельные рабочие узлы: один — для коммуникаций, другой — для автоматизации задач, третий — для интеграций с сервисами.

В некоторых офисах уже собирают целые стойки из Mac mini. Каждый такой «миник» выполняет строго определенную функцию, а в сумме они заменяют несколько операционных ролей внутри команды.

Во главе угла — Clawdbot

В сети Clawdbot частенько сравнивают с ассистентом Тони Старка — Джарвисом. Причин тому несколько. Так, это не просто чат с нейросетью, а полноценный помощник, который умеет работать с приложениями, файлами и сервисами так, как это делал бы человек.

Он пишет и отвечает на сообщения в мессенджерах, управляет файлами на компьютере, автоматизирует повторяющиеся действия и взаимодействует с популярными сервисами вроде Gmail, Notion или GitHub.

При этом бот запоминает контекст, учитывает предыдущие действия и постепенно подстраивается под стиль работы конкретной команды.

Ключевой момент — Clawdbot живет локально, на отдельной машине. Да, это не облачный ассистент, принадлежащий какой-то крупной компании.

Почему стартапы выбирают именно такой формат

Использование Mac mini вместо облачных серверов или виртуальных рабочих столов оказалось неожиданно практичным. Машины легко масштабировать, они не требуют сложной инфраструктуры и обходятся дешевле в долгосрочной перспективе. Один раз купил, настроил и получил «сотрудника», который всегда на месте.

Рассматриваются причины отказа от "Word" подобных инструментов и выбор языка разметки текста AsciiDoc.

Приводится краткое описание функциональных возможностей проекта ODS, версионирование документации в Git, парсинг данных из внешних источников, преобразование и перевод атрибутов БД с помощью LLM-моделей, автоматизация сборки комплектов документов, формирование PDF и публикация документации на сайте используя генератор статических сайтов – Antora.

Проект ODS (Open Documentation Standard) – открытый стандарт и инструментарий для автоматизации процессов создания и поддержки технической документации в ИТ и других проектах. Проект не связан с форматом OpenDocument Spreadsheet (.ods) или проектами Open Data.

В открытом доступе находятся репозиторий и сайт проекта.

Проблемы технической документации

Документация живёт в отдельных файлах, «шаблоны ГОСТ» лежат где‑то в сетевой папке, согласования идут в чате или почте, а изменения в файлах превращаются в бесконечные:

финал_финал_2_исправлено_после_замечаний.docx

С подобными "Word" инструментами всё хорошо, пока документация не развивается и не требует постоянной актуализации. Но когда проекты растут и появляются новые версии, возникают типичные проблемы:

• Проверка и комментарии – сравнение документов плохо похоже на ревью кода, комментарии живут отдельно от истории изменений.
• Повторное использование – «вставить в 17 документов один и тот же фрагмент» почти всегда приводит к поломке стилей и форматированию.
• Стандартизация – трудно гарантировать, что все документы собраны одинаково и в соответствии с шаблонами
• Сборка комплектов – ГОСТ‑комплекты, ведомости и спецификации обычно собираются вручную.

Требования к документированию

Для решения подобных проблем необходимо чтобы документация разрабатывалась как код:

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

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

Выбор пал на AsciiDoc и его инфраструктуру

Для большого массива технической документации необходимо иметь следующий функционал:

• include – сборка документа из блоков;
• атрибуты – объявление переменных и констант с повторным использованием;
• сложные таблицы – заголовки, объединение и выравнивание ячеек;
• ссылки между разделами и файлами с контролируемыми наименованиями;
• диаграммы – возможность встраивать UML и BPMN без скриншотов;
• кастомизация стилей оформления;
• кросс‑компиляция в HTML и PDF.

Открытая экосистема Asciidoctor позволяет максимально реализовать эти требования. Язык разметки AsciiDoc предоставляет мощные средства форматирования контента, а инструменты с открытым исходным кодом дают возможность гибко кастомизировать сборку документации под разные требования.

Проект ODS (Open Documentation Standard)

ODS – это не «ещё один стандарт документации». Это попытка собрать воедино подход "Docs‑as‑Code" для документирования проектов.

Проект должен был соответствовать следующим требованиям:

• единый формат исходного кода документации;
• автоматизация сборки документов и комплектов;
• генерация частей документации из БД и OpenAPI;
• использование LLM‑моделей для рутинных задач;
• публикация документации на сайте с печатными формами.

Структура репозитория построена на основе проекта Antora, которая позволяет собирать компоненты сайта из разных репозиториев, веток и тегов, не переключаясь между ними. Остальные инструменты адаптируются под такую структуру.

Как устроен репозиторий

Репозиторий содержит следующие основные папки проекта:

• components/ – компоненты документации (по смыслу: сервисы, системы, гайды);
• components/<name>/modules/<module>/pages – страницы (Antora формирует HTML из pages);
• components/<name>/modules/<module>/partials – переиспользуемые фрагменты текста, подключаемые через include:: (из partials HTML не формируется);
• docker/ – скрипты для локальной сборки и запуска Docker-образов необходимых для сборки проекта;
• tools/ – Ruby‑инструменты автоматизации и конфигурации;
• templates/ – шаблоны документации;
• antora-playbook.yml – файл конфигурации Antora.

Такая структура позволяет реализовать модульность документации и параллельно вести несколько проектов или систем в одном репозитории.

Система контроля версий (Git) позволяет поддерживать версии комплектов документации используя теги и ветки.

Автоматизация в ODS

Теперь про то, что обычно «ломает» мечту о "Docs‑as‑Code":

• печать по ГОСТ;
• автоматическая генерация контента из БД и API;
• сборка всего комплекта документов.

Главный оркестратор – скрипт tools/start.rb проходит по компонентам из файла конфигурации и, в зависимости от флагов, выполняет:

• Конвертацию BPMN (Node + Puppeteer);
• Конвертацию Draw.io (Node);
• Генерацию AsciiDoc из OpenAPI / Swagger (Ruby);
• Генерацию AsciiDoc и диаграмм из PostgreSQL, преобразование и перевод атрибутов (Ruby, Ollama);
• Генерацию служебных списков, ссылок и таблиц о составе документации, имен файлов и названий документов, количестве листов в документах и т.п. (Ruby);
• Генерацию листов утверждения, спецификаций и ведомостей (Ruby, Asciidoctor PDF);
• Генерацию PDF (Asciidoctor PDF + кастомные конвертеры).

Запуск командой:

ruby tools/start.rb

Запускается скрипт start.rb и выполняется сборка проекта согласно сценарию, заданному в файле config.yml. В результате сборки проекта появляются готовые к печати и/или публикации на сайте PDF документы.

Формирование PDF документов

Инструменты Asciidoctor PDF предоставляют широкие возможности настройки тем оформления документов, но оформление в соответствии с ГОСТ или шаблонами часто упирается в проблемы:

• рамки и штампы;
• нестандартные титульные страницы;
• особые правила нумерации списков и колонтитулов.

Поэтому в ODS генерация PDF построена так:

1. Asciidoctor PDF делает базовую вёрстку контента;
2. Кастомные Ruby‑конвертеры оформляют рамки, титульные страницы, листы утверждения и стилизуют списки.
   

На выходе получается документация оформленная в соответствии с заложенными к ее оформлению требованиями.

Документация из внешних источников

В настоящее время ODS поддерживает генерацию документации из следующих источников:

1. PostgreSQL – таблицы, поля, комментарии, ERD‑диаграммы;
2. OpenAPI / Swagger – структура API, методы, параметры и ответы (могут использоваться как ссылки на swagger, так и файлы в в репозитория json/yml).

В результате парсинга БД и API формируются отдельные asciidoc документы для подключения к основным файлам документации.

Модели ИИ и Ollama

Для преобразования и перевода названий таблиц и атрибутов в полученной документации, при незаполненных в БД полях comment, используется словарь переводов и сервер Ollama предоставляющий CLI и HTTP API с различными языковыми моделями (LLM).

Для задач преобразования и перевода используется промт-файл database_translations.prompt, который отправляется в модель вместе с данными.

Словарь это yml-файл генерируемый скриптом который в свою очередь использует сервис Ollama. При последующих переводах словарь имеет приоритет, а LLM используется пакетно, что позволяет сохранить точность и обеспечить приемлемую скорость при повторных переводах.

Словарь можно править вручную. При появлении новых данных в БД, они транслируются в лог-файл tools/log/database_translations_log.txt.

Логирование удобно для контроля перевода, а при необходимости и ручной правки последних изменений в словаре. Язык перевода может быть задан в файле config.yml в зависимости от используемого в БД.

Сайт документации и Antora

Для публикации документации используется генератор статических сайтов Antora. Он обеспечивает:

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

Автоматически сформированные на предыдущем этапе списки используются Antora для формирования ссылок в навигации и к сформированным PDF‑документам.

Запуск командой:

antora antora-playbook.yml

Antora в ODS отвечает только за сборку сайта. Файл конфигурации antora-playbook.yml используется для самой Antora и установки атрибутов-ключей для условных операторов в Asciidoc и Ruby, которые разделяют сборку PDF и сайта.

Итог

ODS – это попытка сделать техническую документацию:

1. воспроизводимой;
2. версионируемой;
3. связанной с реальными источниками данных;
4. удобной для проверки;
5. автоматически собираемой в готовый комплект.

На практике это помогает поддерживать документацию в актуальном состоянии, ускоряет погружение в проект новых сотрудников, а масштабирование проекта не превращает его документацию в “кладбище файлов”.

Если вы хотите повторить этот подход у себя, практический совет прост: начните с AsciiDoc, подключите Git, научитесь собирать PDF. Всё остальное можно подключать постепенно, когда появится стабильная и понятная структура документации.

Реализацию проекта ODS и публикуемую с его помощью документацию можно посмотреть в открытом репозитории и на сайте. Так же на сайте можно посмотреть ознакомительное видео проекта.

Начиная с 1 марта 2026 года, компания начнет взимать плату за использование self-hosted runners — то есть CI-джоб, которые запускаются на собственном железе пользователя, а не на инфраструктуре GitHub.

Стоимость составит $0,002 за минуту и будет применяться к задачам в приватных репозиториях.

Использование раннеров в публичных репозиториях по-прежнему останется бесплатным. Клиентов GitHub Enterprise Server изменения не затронут.

Что изменится и когда

Изменения вводятся в два этапа:

• 1 января 2026 года GitHub снизит цены на GitHub-hosted runners — в зависимости от типа машины, экономия может достигать 39%.
• 1 марта 2026 года начнет действовать новая плата за self-hosted runners. Эти минуты будут списываться так же, как и обычные минуты GitHub Actions. Их можно будет расходовать за счет бесплатной квоты, включенной в тариф.

При этом сама квота бесплатных минут в тарифах не меняется.

Почему GitHub берет деньги за «чужое» железо

GitHub объясняет решение тем, что даже при запуске CI на собственных серверах пользователи активно используют облачную инфраструктуру GitHub: оркестрацию, API, логирование, безопасность и другие сервисы.

Ранее эти затраты фактически субсидировались за счет платных GitHub-hosted runners.

Новая модель, по словам компании, должна «более честно» распределять стоимость между всеми пользователями и одновременно профинансировать дальнейшее развитие GitHub Actions.

Кого это реально затронет

По оценке GitHub, 96% пользователей не увидят изменений в счете. Из оставшихся 4%:

• у 85% расходы даже снизятся за счет удешевления hosted runners;
• у оставшихся медианный рост составит около $13 в месяц.

Среди индивидуальных разработчиков (Free и Pro-планы), которые используют Actions только в приватных репозиториях, рост расходов затронет всего 0,09% пользователей, при медианном увеличении менее $2 в месяц.

Но вместе с ростом популярности подхода, возник и главный вопрос: насколько безопасен код, который генерирует ИИ-агент?

Исследование показало: функционально — да, безопасно — нет

Ученые из Carnegie Mellon, Columbia и Johns Hopkins выпустили первое крупное исследование безопасности вайб-кодинга.

Они создали собственный бенчмарк SUSVIBES, состоящий из 200 настоящих задач с GitHub-проектов, где ранее были реальные уязвимости (77 видов CWE).

Каждая задача требует внедрения фичи в живой репозиторий размером в сотни тысяч строк. Это максимально приближено к реальной работе.

Далее они протестировали популярных агентов: SWE-Agent, OpenHands и Claude Code. Все они использовали самые свежие ИИ-модели вроде Claude 4 Sonnet, Gemini 2.5 Pro и Kimi K2.

Результаты оказались тревожными:

• 61% решений от лучшей связки (SWE-Agent + Claude 4 Sonnet) — функционально корректны.
• Но только 10,5% — безопасны.
• Иными словами: около 90% рабочего кода, который агент считает «готовым», содержит уязвимости.

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

Какие уязвимости генерируют ИИ-агенты

Исследователи обнаружили весь спектр проблем:

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

Что характерно, в реальных задачах агенты часто пишут код, который выглядит вполне логично. Но они все же упускают один-два критичных условия, создавая легко эксплуатируемые уязвимости.

На визуальных примерах в исследовании видно, что даже маленькие фрагменты вроде verify_password или URL-редиректа превращаются в брешь безопасности, если агент пропускает один шаг — например, нормализацию данных или сравнение времени выполнения.

Вывод

Исследователи подчеркивают: вайб-кодинг полезен для увеличения продуктивности, но категорически непригоден без ручного ревью безопасности.

Особенно это касается тех проектов, которые работают с данными пользователей, авторизацией, сессиями, API или любыми критичными процессами.

ИИ-агент может написать фичу, пройти тесты и выглядеть уверенно. Но с вероятностью около 80–90% там останется дыра, которая в реальной среде превратится в эксплойт.

Одна из самых жестких рецензий пришла от инженера Apple — Рафаэля Багманова. Он заявил, что книга стала «толще, но не умнее». Больше отвлеченных рассуждений, повторов и риторики, а вот практической пользы — меньше.

По его словам, обновленная версия ощущается как смесь Clean Code, Clean Coder, Clean Architecture и блог-постов Роберта Мартина, но без прежней фокусировки.

При этом сам стиль написания кода почти не изменился, а многие проблемы первого издания перекочевали в новое без правок.

«Чрезмерные мини-функции» и странные абстракции

Главная претензия Багманова — навязчивый стиль Tiny Functions: функции с одним параметром, длинные имена, множество маленьких методов, вызванных ради избежания комментариев.

Автор критики приводит пример разбора римских чисел: в книге Мартин превращает простую задачу в набор связанных методов и полей класса. Это усложняет код, а не делает его чище.

Он отдельно подчеркнул, что такой стиль легко узнаваем, но это не комплимент. В примерах «Чистого кода» создается избыточная структура, которую сложнее читать, тестировать и поддерживать.

Слабая работа с производительностью и моделированием

Рафаэль Багманов также отметил, что Мартин игнорирует ключевые аспекты разработки:

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

Особенно досталось примеру с системой аренды помещений: попытка заменить switch на полиморфизм приводит к интерфейсу, который смешивает цену, налоги и скидки в одной сущности:

В реальных системах так не работает — налоговые правила зависят от региона, периода и категории товара, а не от «класса предмета».

Комментарии: редкие хорошие примеры и странная позиция

Несмотря на то, что Мартин снова заявляет, что комментарии — «признак провала», книга почти не показывает хороших примеров того, как писать нужные комментарии.

Инженер Apple подчеркивает: в реальном мире комментарии — не зло, а инструмент. И хорошую мысль проще объяснить текстом, чем ломать архитектуру ради самодокументируемости.

Итог: книга стала объемнее, но не глубже

В итоге Багманов пришел к выводу, что второе издание «Чистого кода» скорее разочаровывает. Оно наследует стиль, который не подходит современным языкам и практикам, усиливает слабые стороны первого издания и добавляет многословие без реальных улучшений.

Для инженеров, которые ищут современные советы по дизайну, сопровождению и архитектуре, книга в 2025 году выглядит устаревшей. Но что хуже всего, вводящей новичков в заблуждение.

Эта статья написана с помощью сервис . Исходник — видео и гайд про новые t-строки в Python 3.14.

Эволюция форматирования строк в Python

Процентный стиль (%) — с самого начала

Python умел форматировать строки через процент с первых версий:

Класс Template — Python 2.4

В модуле string появился альтернативный способ:

Метод format() — Python 2.6

Форматирование стало компактнее:

F-строки — Python 3.6

Этот синтаксис быстро стал стандартом де-факто:

T-строки — Python 3.14

Новый инструмент для отложенной интерполяции:

Когда использовать t-строки

Для разработчиков приложений

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

Для авторов библиотек

T-строки полезны при разработке библиотек, где пользователям нужна отложенная интерполяция. Типичные сценарии:

• Экранирование SQL-запросов перед выполнением
• Обработка HTML перед рендерингом
• Работа с регулярными выражениями
• Предварительная обработка данных перед объединением в строку
• Отложенная интерполяция (как в модуле logging)

Отличия f-строк от t-строк

Ключевое различие: f-строки выполняют интерполяцию немедленно и возвращают готовую строку, t-строки возвращают объект Template с отложенной интерполяцией.

Проблема, которую не решают f-строки

Рассмотрим функцию dedent из модуля textwrap, которая удаляет общие отступы из текста:

Результат:

Функция корректно убирает общие отступы, но сохраняет относительные:

Результат:

Где f-строки создают проблему

Возьмём многострочный код:

Попробуем вставить его в f-строку и передать в dedent:

Получаем некорректный результат:

Первая строка кода имеет отступ, остальные — нет. Вся выходная строка обработана неправильно.

Причина проблемы

F-строка выполняет интерполяцию до того, как результат попадает в dedent. К этому моменту функция не может понять, как выглядела исходная строка до подстановки значений.

F-строка взяла строку без общих отступов (code) и поместила её внутрь строки с отступами. Когда итоговая строка попала в dedent, функция не смогла корректно определить, что нужно было сначала добавить отступы к подставляемому значению, а потом убрать общие отступы.

Функция dedent не может посмотреть историю и понять структуру исходной f-строки.

Как работают t-строки

T-строки возвращают объекты Template

F-строка возвращает готовую строку:

T-строка возвращает объект Template:

Итерация по объекту Template даёт смесь строковых фрагментов и объектов интерполяции:

Применение t-строк

Объект Template позволяет библиотекам предварительно обрабатывать интерполируемые части перед финальной сборкой строки.

Решение проблемы dedent с t-строками

Используем t-строку вместо f-строки:

Корректный результат:

Версия dedent, работающая с t-строками, видит, что подставляемое значение имело относительные отступы внутри более крупной строки, но само содержимое не было с отступами. Функция корректно применяет отступы к подставляемому значению перед удалением общих отступов у всей строки.

Реализация dedent для t-строк

Кастомная версия dedent для работы с t-строками:

Функция выполняет следующие операции:

1. Использует стандартный dedent из модуля textwrap
2. Обрабатывает каждое интерполируемое значение в зависимости от его содержимого
3. Учитывает позицию значения внутри более крупной строки
4. Корректно применяет отступы перед финальной обработкой

Эта реализация доступна в виде библиотеки better-dedent в индексе пакетов Python:

Автор предупреждает, что библиотека может содержать баги, поэтому сообщайте о найденных проблемах в репозитории проекта.

Вывод по t-строкам: нужны или нет

Писать t-строки просто

Синтаксис t-строки идентичен f-строке, меняется только префикс:

Работать с Template сложнее

Работа с объектом Template, который возвращает t-строка, требует понимания его структуры: нужно уметь итерироваться по частям и обрабатывать интерполяции.

В большинстве случаев вы не будете напрямую работать с t-строками и объектами Template в повседневном коде. Вы будете передавать их в библиотеки, которые специально разработаны для приёма t-строк.

Если библиотека поддерживает t-строки — передайте ей t-строку. Всё остальное библиотека обработает сама.

Перспективы t-строк

Python 3.14 вышел недавно, поэтому примеров использования t-строк в реальных проектах пока немного. Создатели t-строк ведут список awesome t-string для тех, кто хочет следить за развитием экосистемы.

Следите за обновлениями библиотек, которыми вы пользуетесь — возможно, скоро они начнут поддерживать t-строки для более гибкой работы со строками.

Злоумышленники внедрили вредоносный код в 492 пакета, суммарно набирающих более 132 млн загрузок в месяц. Если такой пакет устанавливает разработчик, вредонос запускается еще до завершения установки и получает доступ к его среде разработки.

Отметим, что текущая кампания стала «вторым пришествием» Shai Hulud. Злоумышленники приурочили ее к декабрьской блокировке старых npm-токенов. Атакующие явно рассчитывали успеть нанести максимальный урон до обновления безопасности.

Как работает новая версия Shai Hulud

По сравнению с атакой в сентябре, вредонос стал агрессивнее. И заметно опаснее:

• теперь он устанавливает Bun и запускает основную вредоносную логику через bun_environment.js;
• создает случайный GitHub-репозиторий и складывает туда украденные токены и ключи;
• пытается заразить до 100 пакетов, а не 20, как раньше;
• если не удается авторизоваться в GitHub или npm, вредонос стирает все файлы в домашней директории пользователя.

Внутри зараженного пакета находится setup_bun.js, который либо запускает вредонос напрямую, либо подготавливает окружение, чтобы тот мог работать.

В некоторых скомпрометированных пакетах второй файл отсутствует — исследователи считают это ошибкой самих атакующих, которая частично снизила масштаб атаки.

Кто пострадал

Под удар попали проекты AsyncAPI, PostHog, Postman, Zapier, ENS и десятки независимых разработчиков. Первые зараженные пакеты появились примерно в 6 утра по Москве, после чего атака быстро распространилась на крупные экосистемы.

Исследователи обнаружили также скомпрометированную ветку в репозитории AsyncAPI CLI — вероятно, заражение отдельных проектов шло через те же методы, что и в предыдущей атаке на Nx.

Что похищают злоумышленники

Вредонос автоматически запускает TruffleHog и ищет в системе:

• ключи GitHub и npm,
• токены облаков и CI/CD,
• пароли, API-ключи и любые другие секреты.

Если атакующие получат токены для публикации npm-пакетов или доступа к репозиториям, они могут продолжить цепочку атак и заражать новые проекты.

Что делать командам безопасности

Пока специалисты продолжают анализировать атаку, есть ряд мер, которые можно предпринять уже сейчас:

• проверить все зависимости, особенно пакеты AsyncAPI, PostHog, Postman, Zapier, ENS;
• срочно ротировать GitHub, npm и облачные ключи, использовавшиеся в процессе разработки или CI;
• искать подозрительные GitHub-репозитории с пометкой “Sha1-Hulud: The Second Coming”;
• максимально ограничить или отключить postinstall-скрипты в CI;
• зафиксировать версии зависимостей и включить обязательную MFA на npm и GitHub;
• использовать инструменты фильтрации вредоносных пакетов в цепочке поставок.

Атака продолжает развиваться — следим за обновлениями.

Об этом он рассказал в интервью на Open Source Summit в Сеуле.

«Я уже 20 лет не программист»

Торвальдс признался, что своей основной задачей давно не считает написание кода:

«Около 20 последних лет я не программист. Я смотрю на Git со стороны, а в ядре моя роль — соглашаться или отказывать».

Он отметил, что все чаще приходится «говорить да» новым идеям, несмотря на сопротивление старых мейнтейнеров. Это можно заметить, например, в вопросе интеграции Rust в ядро Linux.

Что он думает об ИИ и разработке

Несмотря на то, что сам Линус не пользуется ИИ-ассистентами, он не исключает, что такие инструменты могут пригодиться в ядре. Основная проблема ИИ сейчас, по его словам — не код, а инфраструктура:

«ИИ-краулеры сильно захламляют наши ресурсы, притаскивают баги и репорты, которых не существует».

При этом Торвальдс позитивно оценивает влияние ИИ-бума на индустрию: из-за него NVIDIA стала «значительно более хорошим игроком» в Linux-сообществе.

А что с вайб-кодингом?

Именно здесь Линус удивил больше всего. Он сказал, что относится к вайб-кодингу «довольно позитивно», потому что он:

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

Но использовать это в реальных проектах — гиблая идея:

«Это может быть ужасным решением с точки зрения поддержки».

По мнению Торвальдса, вайб-кодинг — отличная «точка входа», но плохой фундамент для сложных систем вроде ядра Linux.

Вердикт Линуса

Он видит ИИ как обычный инструмент — как когда-то компиляторы, которые избавили разработчиков от необходимости писать код ассемблера вручную:

«ИИ не убьет профессию. Как и компиляторы, он просто повысит продуктивность».

Модель уже встраивают почти во все ключевые продукты Google — от поиска до инструментов для разработчиков.

Что такое Gemini 3

Gemini 3 представляет из себя новое семейство моделей. Основным флагманом в нем выступает Gemini 3 Pro, а для сложных задач появится отдельный режим Gemini 3 Deep Think.

По сути, это эволюция сразу в трех направлениях:

• Мультимодальность — текст, код, картинки, видео, аудио в одном стеке.
• Reasoning и «глубокое мышление» — лучше решает сложные задачи по науке, математике и планированию.
• Агентность — модель умеет не только отвечать, но и выполнять цепочки действий: работать с браузером, почтой, кодом.

Google отдельно подчеркивает: при создании Gemini 3 авторы метили не в «просто чат для общения», а в «ИИ, который помогает доводить любую идею до реализации».

Чем Gemini 3 отличается от 2.5

По заявлениям Google, Gemini 3 Pro:

• заметно обгоняет Gemini 2.5 Pro в большинстве бенчмарков по математике, логике, точности фактов;
• лучше понимает контекст и намерение — нужно меньше «танцев с промптами»;
• умеет генерировать код для сложных визуализаций, интерфейсов и 3D-сцен;
• работает как «thought partner» — пытается сокращать воду и говорить по делу, а не льстить.

Отдельный режим Gemini 3 Deep Think дает еще больший прирост в задачах на логику и новизну, но пока доступен только безопасностным тестерам. Позже появится и у подписчиков Google AI Ultra.

Где уже можно попробовать

Gemini 3 начинают раскатывать сразу «в масштабах Google»:

• Поиск (AI Mode в Search) — генерируемые ответы, визуальные раскладки, интерактивные элементы, симуляции.
• Приложение Gemini — для обычных пользователей и подписчиков Google AI Pro/Ultra.
• Для разработчиков: Google AI Studio, Vertex AI, Gemini CLI, новый агентный IDE-платформер Google Antigravity.
• Интеграции: Cursor, GitHub, JetBrains, Replit и другие сторонние инструменты.

Google Antigravity: агент как напарник, а не просто советчик

Отдельно Google показала Antigravity — «agent-first» платформу для разработки:

• агент получает доступ к редактору, терминалу и браузеру;
• может сам планировать и выполнять end-to-end задачи (например, собрать приложение, проверить, запустить, поправить баги);
• под капотом — Gemini 3 + специализированная модель для управления компьютером и модель для работы с картинками.

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

Безопасность и «шаг к AGI»

Google утверждает, что Gemini 3 — их «самая проверенная» и «самая безопасная» модель:

При этом в компании также заявляются: Gemini 3 это крупный шаг к более общему интеллекту, а не просто очередная версия чат-бота.

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

Что делает Code Wiki

Сервис сканирует весь репозиторий, строит структурированную wiki-документацию и перегенерирует ее после каждого коммита.

Таким образом, мы получаем не просто статичный README и не набор заметок. Локальная «Википедия по проекту» остается синхронизированной с кодовой базой всегда. Google подчеркивает несколько ключевых возможностей:

• Автоматическая документация. Code Wiki описывает архитектуру, модули, классы, функции. Причем делает это регулярно, без участия разработчика.
• Глубокий контекст. Встроенный чат на базе Gemini использует сгенерированную wiki как базу знаний. В итоге мы получаем не «общий» ИИ, а агента, который знает репозиторий целиком.
• Навигация по коду. Все элементы документации связаны гиперссылками с исходниками — можно сразу перейти от объяснения к конкретной строчке реализации.
• Диаграммы. Сервис автоматически рисует актуальные архитектурные, sequence- и class-диаграммы, которые меняются вместе с кодом.

По задумке Google, новая система должна сократить время входа в проект: новичок сможет ориентироваться в большом репозитории в первые часы, а не через неделю.

Что дальше

Пока Code Wiki работает только с публичными проектами. Но Google уже делает CLI-расширение для Gemini, которое позволит генерировать документацию для закрытых, внутренних кодовых баз — локально и без передачи данных в облако.

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

Зачем все это

Google утверждает, что эпоха написанных вручную устаревающих документов заканчивается. Разработчики все чаще пишут код с ИИ-помощниками, но все еще тратят огромные усилия на чтение чужого.

Code Wiki должен закрыть этот пробел и превратить понимание кода в операцию, которая занимает минуты. Сервис уже работает в виде публичного превью на codewiki.google.

Пока нейросеть пишет код, программист может смотреть TikTok, листать Tinder или играть в мини-игры.

Проблема, о которой никто не говорил

Создатели Chad IDE заявляют, что современные инструменты вроде GitHub Copilot породили новую форму «кризиса продуктивности». Мол пока ИИ пишет код, разработчик вынужден просто ждать.

Исследование команды показало, что 87% инженеров в этот момент тянутся к телефону. И, по данным самих авторов, теряют по 5–10 минут на пролистывание соцсетей после каждой генерации.

Так появился концепт «engagement-driven development» — разработки без скуки.

Как это работает

Chad IDE добавляет в окно разработки развлечения «с пользой для фокуса». Ключевая идея — не дать разработчику покинуть IDE, но при этом удержать внимание в контексте проекта.

Основные функции

• Active Generation Monitoring — визуализирует процесс генерации кода, добавляя анимации и контекстные подсказки.
• Micro-Interactions — легкие интерактивные элементы, которые не мешают, но отвлекают от телефона.
• Context Preservation — IDE «напоминает», над чем вы работаете, даже если вы смотрите видео.

Интеграции

Chad IDE поддерживает сервисы, которые обычно отвлекают. Теперь они используются «для концентрации»:

• TikTok и *Instagram Reels — вертикальные видео прямо в редакторе, автопауза при фокусе на коде.
• YouTube Shorts — подборка видео о программировании.
• Tinder — свайпы с «кодовыми» айсбрейкерами для разработчиков.
• Мини-игры — казуальные игры во время компиляции.

Авторы уверяют, что эти функции не мешают, а наоборот — предотвращают контекстные переключения.

Эффект: «меньше скуки — больше кода»

По данным внутреннего тестирования:

• количество отвлечений снизилось на 43%;
• время, потерянное на телефон, сократилось на 2,3 часа в день;
• продолжительность «состояния потока» выросла на 67%;
• а раздражение из-за долгих генераций — на 89% меньше.

Один из тестировщиков из *Meta назвал IDE «фиджет-спиннером для мозга, который держит тебя в контексте кода».

*Компания Meta и ее продукты признаны экстремистскими, их деятельность запрещена на территории РФ

Продуктивность разработчика повышается, когда к VSCode подключены инструменты для командной работы, контейнеризации и анализа данных. В статье по шагам разобрали, как интегрировать VSCode с GitLab, Docker и Jupyter.

Зачем всё это подключать

VSCode из коробки умеет работать с Git. Но когда ваш репозиторий лежит на GitLab, хочется создавать merge request прямо из редактора, просматривать pipeline, работать с issues.

Docker решает проблему «у меня работает, а у тебя нет». Вы пишете код в контейнере с одними версиями библиотек, и любой член команды запустит точно такое же окружение.

Jupyter традиционно запускают в браузере. Но переключаться между браузером и редактором неудобно. VSCode умеет работать напрямую — редактируете код, запускаете ячейки, смотрите графики в одном окне.

Как подключить VSCode к GitLab

Шаг 1. Устанавливаем расширение

Откройте VSCode и нажмите Ctrl+Shift+X. В поиске введите «GitLab Workflow». Установите официальное расширение. После установки в левой панели появится иконка GitLab.

Шаг 2. Получаем токен доступа

Расширению нужен способ общаться с вашим GitLab-сервером. Для этого создадим персональный токен:

1. Зайдите в GitLab через браузер.
2. Кликните на аватар >> Settings >> Access Tokens.
3. Придумайте название токена.
4. Выберите срок действия.
5. Отметьте галочками права доступа: api, read_user, read_repository, write_repository.
6. Нажмите «Create personal access token».
7. Скопируйте токен — он покажется только один раз.

Шаг 3. Настраиваем расширение

Вернитесь в VSCode. Нажмите Ctrl+Shift+P и введите «GitLab: Add Account». Расширение попросит два параметра:

• GitLab instance URL — адрес вашего GitLab (например, https://gitlab.com или адрес корпоративного сервера).
• Personal Access Token — токен, который только что создали.

Вставьте токен и нажмите Enter. Если всё правильно, в статус-баре внизу появится ваше имя пользователя GitLab.

Шаг 4. Работаем с проектом

Попробуем клонировать проект. Нажмите Ctrl+Shift+P и выберите «GitLab: Clone from GitLab». Расширение покажет список доступных проектов. Выберите нужный, укажите папку для клонирования.

Теперь вам доступны функции Git:

• Pipeline — в боковой панели GitLab видны все запущенные сборки, их статусы и логи.
• Issues — создавайте, редактируйте и закрывайте задачи прямо из редактора.
• Merge requests — посмотрите список MR, оставьте комментарии к коду, одобрите изменения.
• Snippets — сохраняйте фрагменты кода для повторного использования.

Как подключить VSCode к Docker

Редактор умеет запускать код прямо внутри контейнера. Вы редактируете файлы, а выполняются они в изолированной среде с выбранными настройками.

Шаг 1. Подготовка

Установите Docker Desktop с официального сайта. После установки убедитесь, что Docker запущен — в системном трее должна появиться иконка кита.

В VSCode установите два расширения:

• Docker.
• Dev Containers.

Шаг 2. Создаём Dockerfile

В корне проекта создайте файл Dockerfile. Пример для Python-проекта:

Этот файл говорит Docker:

1. Возьми базовый образ Python 3.11.
2. Создай рабочую директорию /app.
3. Скопируй и установи зависимости.
4. Скопируй весь код проекта.
5. При запуске выполни команду python main.py.

Шаг 3. Настраиваем Dev Container

Создайте папку .devcontainer в корне проекта. Внутри создайте файл devcontainer.json:

Конфигурация использует ваш Dockerfile для сборки контейнера. Она автоматически устанавливает Python-расширения внутри контейнера, пробрасывает порт 8000 (если у вас веб-приложение) и выполняет команду после создания контейнера.

Шаг 4. Запускаем разработку в контейнере

Нажмите Ctrl+Shift+P и выберите «Dev Containers: Reopen in Container». Редактор соберёт Docker-образ по вашему Dockerfile, запустит контейнер, подключится к нему и откроет ваш проект уже внутри контейнера.

Теперь весь код выполняется в изолированной среде. Терминал в VSCode работает внутри контейнера. Расширения устанавливаются в контейнер, отладчик запускает код там же.

Как подключить VSCode к Jupyter

В классическом интерфейсе нет нормального автодополнения кода, сложно работать с Git, неудобно рефакторить код и нет полноценной отладки. Плагины VSCode решают эти проблемы.

Шаг 1. Установка

Установите расширение «Jupyter» от Microsoft. Оно автоматически подтянет все необходимые зависимости.

В терминале установите Jupyter и ipykernel:

Шаг 2. Создаём первый ноутбук

Создайте файл с расширением .ipynb или нажмите Ctrl+Shift+P >> «Create: New Jupyter Notebook».

VSCode откроет интерфейс ноутбука. Вверху вы увидите панель инструментов с выбором ядра, кнопки запуска и добавления ячеек.

Шаг 3. Выбираем ядро

Кликните на «Select Kernel» в правом верхнем углу. VSCode покажет список доступных интерпретаторов:

• Локальные Python-окружения.
• Виртуальные окружения (venv, conda).
• Docker-контейнеры (если настроены).
• Удалённые Jupyter-серверы.

Выберите нужное окружение. VSCode запомнит выбор для этого ноутбука.

Шаг 4. Пишем и выполняем код

В ячейке напишите код:

Нажмите Shift+Enter для выполнения ячейки. График отобразится прямо под кодом.

Для Python-файлов можно включить интерактивный режим. Добавьте комментарий # %% в .py файл:

VSCode покажет кнопки «Run Cell» над каждым блоком. Теперь можно выполнять код частям.

Что в итоге

Первая настройка VSCode с GitLab, Docker и Jupyter занимает 30-40 минут. В итоге вы получаете единое рабочее пространство для ваших задач разработки.

Начните с GitLab и научитесь создавать merge requests из редактора. Потом добавьте Docker для одного проекта. Когда освоитесь, подключите Jupyter для работы с данными. Инструменты решают разные задачи, а VSCode объединяет их функции в одном интерфейсе.

Возьмите проект и последовательно подключите каждый инструмент. Через неделю удивитесь, как раньше работали без этой связки. Код пишется быстрее, ошибок меньше, а переключений между окнами почти нет.

Если что-то непонятно или не получается настроить — пишите в комментариях, разберёмся вместе!

Об этом рассказал глава прикладного и инженерного направлений ChatGPT Сулман Чоудри в беседе с Гергели Оросом, автором известной техрассылки The Pragmatic Engineer.

По словам Ороса, в OpenAI активно развивается новая модель — связка «super senior + super junior». Опытный инженер отвечает за архитектуру и стратегические решения, а «супер-джун» берет на себя скорость и гибкость. Он использует ИИ-инструменты на уровне, недоступном старшим коллегам.

«Один из таких джуниоров обиделся, когда его спросили, не помог ли ему Codex. Для него это слишком просто. Он использует сразу несколько экземпляров Codex, которые общаются между собой и выполняют разные части задачи», — рассказывает Орос.

Эти специалисты — представители нового поколения «AI-native» инженеров, для которых взаимодействие с языковыми моделями — базовый навык, сродни владению Git или терминалом.

Они умеют быстро запускать несколько агентов, делить задачи между моделями и интегрировать результаты в код.

Программы OpenAI для ранней карьеры

Все это логично вписывается в собственные инициативы OpenAI — Residency и Emerging Talent. Там прямо говорится, что компания берет людей «на переходе» между non-tech и IT, если они способны быстро осваивать инженерные принципы с помощью ИИ.

«Мы ищем людей, которые думают, как инженеры, даже если у них нет традиционного опыта разработки», — говорится в описании программ.

Контраст с рынком

На общем фоне это решение выглядит почти парадоксально. 2025-й стал годом, когда большинство IT-компаний сократили junior-позиции: автоматизация и рост LLM-ассистентов сделали базовую разработку избыточной. Но OpenAI, наоборот, делает ставку на специалистов, выросших в новой парадигме — тех, кто умеет кодить через ИИ, а не вместо него.

Эксперты называют это возможным сдвигом в отрасли: если стратегия OpenAI сработает, за ней могут последовать другие компании, начав формировать команды, где ключевым навыком станет не знание конкретного языка, а умение мыслить и строить системы в симбиозе с моделями.

Редакция Tproger сделала и адаптировала перевод подборки программ для Windows и macOS. Здесь вы найдёте проверенные временем решения для работы, развлечений и повседневных задач. Мы сосредоточились на бесплатных и условно-бесплатных приложениях с отличной репутацией, которые решают реальные задачи без навязывания ненужных функций.

Список разбит по категориям: от браузеров и гейминга до утилит безопасности и инструментов для продуктивности.

Неважно, опытный вы пользователь или новичок — здесь найдётся что-то полезное для каждого.

Браузеры

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

• Большинство пользователей: Chrome, Edge или Safari
• Защита приватности: Firefox, Brave, Ungoogled Chromium
• Опытные пользователи: Vivaldi
• Максимальная анонимность: Tor Browser

Google Chrome

Chrome остаётся самым популярным браузером в мире — и не просто так. Он быстрый, стабильный и отлично интегрируется с экосистемой Google. Огромная библиотека расширений из Chrome Web Store позволяет настроить браузер под любые задачи. Синхронизация между устройствами работает безупречно: вкладки, пароли, закладки и история всегда под рукой.

Минус один, но существенный: Chrome прожорлив. Если у вас открыто больше десятка вкладок, он может съесть несколько гигабайт оперативной памяти. На компьютерах с 8 ГБ RAM и меньше это становится проблемой.

Mozilla Firefox

Firefox — это выбор тех, кто ценит приватность и открытость. Mozilla не зарабатывает на продаже ваших данных, а сам браузер активно развивается сообществом. Встроенные инструменты защиты от трекинга работают из коробки, блокируя рекламные сети и скрипты слежения.

По скорости Firefox не уступает Chrome, а по потреблению памяти даже выигрывает. Библиотека расширений чуть меньше, чем у Chrome, но все основные инструменты доступны.

Microsoft Edge

Edge построен на том же движке Chromium, что и Chrome, но при этом лучше оптимизирован для Windows. Microsoft вложилась в производительность: браузер работает быстро, потребляет меньше ресурсов и отлично интегрируется с системой.

Особенно приятны функции вроде Collections (коллекции вкладок для организации исследований), режим чтения и встроенный скриншотер. Edge поддерживает все расширения Chrome, так что переход безболезненный.

Brave

Brave — это Chrome на стероидах приватности. Браузер блокирует рекламу и трекеры по умолчанию, что делает сёрфинг быстрее и безопаснее. При этом он полностью совместим с расширениями Chrome.

Есть интересная фишка: Brave Rewards позволяет зарабатывать криптовалюту за просмотр приватной рекламы (если захотите её включить). Спорная механика, но как опция — почему нет. Для тех, кто хочет Chrome без Google и с упором на приватность, Brave — отличный выбор.

Safari (только macOS)

Если у вас Mac, Safari заслуживает внимания. Это самый энергоэффективный браузер для macOS: на MacBook он даёт ощутимо больше автономности по сравнению с Chrome или Firefox. Интеграция с экосистемой Apple безупречна: Handoff, синхронизация через iCloud, Reading List, автозаполнение паролей.

Safari быстрый, безопасный и не перегружен функциями. Единственный минус — библиотека расширений заметно скромнее, чем у конкурентов. Но для большинства задач базового функционала хватает.

Ungoogled Chromium

Для ультраосторожных Ungoogled Chromium удаляет всё отслеживание и сервисы Google — но вам придётся настраивать всё самостоятельно, так как в нём нет автообновлений или встроенной синхронизации.

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

Tor Browser

Выводя приватность на следующий уровень, Tor Browser маршрутизирует ваш трафик через сеть Tor, анонимизируя ваш IP и многократно шифруя соединение. Он медленнее по задумке, но идеален, если ваш приоритет — максимальная анонимность, а не скорость или удобство.

Vivaldi

Vivaldi — браузер мечты для тех, кто хочет полного контроля. Стекирование вкладок, тайлинг, кастомные горячие клавиши, встроенная почта и календарь, веб-панели — это полноценный десктопный опыт внутри браузера. Хотите боковую панель браузера, открывающую ваши заметки, RSS-ленты или любой нужный сайт? Vivaldi это умеет.

Arc

Наконец, Arc — когда-то новичок на рынке браузеров, нацеленный на переосмысление UX: замена традиционной панели вкладок на боковую панель, акцент на веб-приложениях, интегрированные разделённые виды и easels для заметок и доски. К сожалению, компания за Arc прекратила разработку, чтобы полностью переключиться на ИИ с новым браузером, который сейчас в закрытой бета-версии.

Управление паролями

• Лучший бесплатный выбор: Bitwarden
• Также отлично: 1Password, Dashlane, KeePass

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

Также не будем забывать о passkeys (ключах доступа). Если говорить практически, можно сказать, что passkeys объединяют концепцию пароля и двухфакторной аутентификации (2FA) в одно плавное действие, но гораздо безопаснее и гораздо менее раздражающе.

Bitwarden

Полностью опенсорсный, зашифрованный и щедрый даже в бесплатной версии. Вы получаете неограниченное количество паролей, синхронизацию между устройствами и приложения для всех платформ. Премиум ($10/год) добавляет безопасный обмен файлами и инструменты 2FA. Также есть доступные семейные и командные планы.

1Password

Премиум-решение с отполированным интерфейсом, сильной кроссплатформенной поддержкой и отличными функциями вроде Travel Mode (режим путешествий) и полной интеграцией passkeys.

Dashlane

Предлагает мониторинг даркнета, интеграцию VPN и плавный пользовательский опыт. Есть бесплатный тариф с ограниченными функциями, но премиум-версия конкурентоспособна.

KeePassXC

Отличная оффлайн-альтернатива, если хотите полного контроля и не против ручной синхронизации (или использования чего-то вроде Syncthing или Dropbox для синхронизации базы данных).

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

Продвинутые утилиты и дополнения к ОС

• Поиск + лаунчеры: Everything или Wox (Windows), Alfred или Raycast (macOS)
• Пакетные менеджеры: WinGet, Homebrew (macOS)
• Для пользователей Windows: PowerToys
• Для пользователей Mac: Rectangle
• История буфера обмена: ClipClip, Flycut (macOS)
• Скриншоты + аннотации: Monosnap

Winget

Официальный менеджер пакетов Microsoft, встроенный в Windows 10 и 11. Работает похоже на Chocolatey, но разработан и поддерживается Microsoft. Homebrew — самый популярный менеджер пакетов для macOS. Позволяет быстро устанавливать, обновлять и управлять приложениями и CLI-инструментами с помощью команд в терминале.

Everything

Что касается поиска, Everything остаётся золотым стандартом сверхбыстрого поиска по именам файлов в Windows. Он индексирует диски за секунды и выдаёт почти мгновенные результаты с минимальной нагрузкой на систему. Если нужен функционал шире базового поиска, Wox использует движок Everything и добавляет мощные возможности лаунчера: поиск файлов, запуск приложений, калькулятор, перевод текста и расширения через плагины. Получается более гибкий опыт в духе Spotlight для Windows.

Command Palette/Alfred/Raycast

В который раз Microsoft не смогла существенно улучшить встроенный поиск Windows, хотя Command Palette в PowerToys даёт неплохой компромисс для тех, кто не хочет ставить сторонние утилиты.

На macOS Alfred по-прежнему главный лаунчер и утилита поиска. Он быстрый, интуитивный и в бесплатной версии включает историю буфера и настраиваемые поиски; расширенная автоматизация и «воркфлоу» доступны в Powerpack.

Тем, кто хочет современную облачно-интегрированную альтернативу с готовыми расширениями и встроенной поддержкой Notion, GitHub и Slack, стоит присмотреться к Raycast — это стильный, дружественный к разработчикам вариант, который стремительно набирает популярность.

Менеджеры буфера обмена

Они позволяют возвращаться к ранее скопированному — тексту, изображениям, ссылкам — и сильно ускоряют рутинные операции.

В Windows встроенная история буфера (Win + V) кое-как выручает, но продвинутым пользователям обычно хочется большего. В числе бесплатных рекомендаций — ClipClip для Windows и Flycut для macOS.

Когда речь о скриншотах и аннотациях, штатные инструменты macOS и Windows заметно выросли. Но многим всё равно удобнее сторонние решения. Нам по-прежнему нравится Monosnap за простоту и возможность мгновенно заливать снимки в облако для шаринга (и это бесплатно).

PowerToys — набор полезных утилит от Microsoft для продвинутых пользователей Windows, повышающих продуктивность и упрощающих рабочие процессы. Среди инструментов: FancyZones для продвинутого раскладывания окон, PowerRename для пакетного переименования, Keyboard Manager для ремапинга клавиш, универсальный color picker и другие.

Rectangle и Magnet — два самых популярных приложения на macOS для закрепления окон: быстрые выравнивание и ресайз по хоткеям или перетаскиванием, примерно как по умолчанию в Windows. Пользователям, пришедшим с Windows и скучающим по системному снапингу, одно из них жизненно необходимо.

Широко используемая альтернатива в Windows — FancyZones (часть PowerToys), предлагающая продвинутое управление окнами: настраиваемые сетки, зоны привязки и поддержку нескольких мониторов — поэтому это фаворит пауэр-пользователей на Windows.

Для рутины и создания проектов

• Бесплатные инструменты: FreeOffice, LibreOffice и WPS Office
• Microsoft Office за единовременную плату $49, Office 2024 — $129
• Заметки: Notion, OneNote, Obsidian
• Бесплатный PDF-редактор: PDFsam
• Почтовые клиенты: Thunderbird, eM Client

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

Microsoft Office остаётся отраслевым стандартом для профессиональной продуктивности. Подписка Microsoft 365 открывает доступ к Word, Excel, PowerPoint, Outlook и включает 1 ТБ облачного хранилища.

Среди бесплатных альтернатив LibreOffice — мощный open-source комплект с сильным сообществом (хотя интерфейс некоторым кажется старомодным). Если нужна внешне более майкрософтовская альтернатива, попробуйте FreeOffice или WPS Office Free — у них хорошая совместимость.

На macOS Pages, Numbers и Keynote предустановлены и более чем достаточны для большинства задач, особенно если вы в экосистеме Apple.

Знания и ведение заметок

Notion стал универсальной платформой организации: заметки, базы данных, to-do, управление проектами, создания совместных рабочих пространств. Если нужны более локальные заметки с синхронизацией между устройствами и поддержкой Markdown, Obsidian — любимец студентов и исследователей.

Для быстрых кроссплатформенных заметок OneNote — крепкий бесплатный вариант от Microsoft. В качестве альтернатив — Simplenote или open-source Joplin.

Если вы занимаетесь академической работой и научными статьями, Zotero — отличный open-source менеджер источников с интеграцией в браузер и совместными коллекциями. Milanote предлагает визуальный подход к заметкам и планированию — идеально для креативных пользователей.

Работа с PDF

Хотя Adobe Acrobat остаётся премиальным редактором PDF, бесплатные альтернативы вроде PDFsam позволяют без усилий объединять, разбивать, редактировать и поворачивать страницы.

Инструменты для дизайна и создания контента

Для дизайна два выделяющихся приложения хорошо дополняют набор продуктивности. Figma Desktop — совместная платформа интерфейс-дизайна, широко используемая UI/UX-дизайнерами и фронтенд-разработчиками. Десктоп-версия работает быстрее, чем браузер, и лучше интегрируется с ОС — это удобно для сложных дизайн-систем и коллаборации в реальном времени.

Canva с интуитивным drag-and-drop превосходно чувствует себя и как десктоп-приложение. Отлично подходит для быстрых графических материалов для соцсетей, маркетинга, постеров и презентаций. Благодаря тысячам шаблонов и совместной работе это фаворит как у профи, так и у новичков.

Почтовые клиенты

Если вы предпочитаете отдельный почтовый клиент, у eM Client много функций, бесплатный — до двух аккаунтов. Mozilla Thunderbird — мощная open-source альтернатива с удобной настраиваемостью, а Mailbird — вариант с упором на продуктивность для тех, кого не пугает подписка.

Инструменты разработчика

• Редакторы кода и текста: VS Code, Cursor, Sublime Text
• Система контроля версий: SourceTree, GitHub Desktop
• Контейнеры: Docker
• Локальные LLM: Ollama
• SFTP, загрузка файлов: WinSCP, Forklift

Для разработчиков Visual Studio Code — безусловный вариант. Бесплатный, лёгкий, но мощный, кроссплатформенный — тысячи расширений покрывают практически любой язык, фреймворк или инструмент. Набирающая популярность альтернатива — Cursor, редактор на базе VS Code с усиленной AI-помощью. Он подходит для связки с LLM: даёт inline-подсказки, генерирует код, рефакторит и позволяет редактировать кодовую базу.

При этом Sublime Text остаётся для скорости и простоты, а Notepad++ — отличный лёгкий редактор для быстрых правок в Windows.

Для Git графические клиенты SourceTree и SmartGit дают понятный интерфейс для управления репозиториями на GitHub, GitLab и не только. GitHub Desktop раньше был простоват и не слишком хорош, но сейчас существенно прибавил — всё ещё простой для работы, но в хорошем смысле.

Для локальных окружений, API-тестирования или терминального воркфлоу инструментов — пруд пруди. Например, Docker Desktop стал стандартом для тех, кто собирает и запускает контейнеризированные приложения на разных платформах. Он упрощает настройку окружений и держит систему чистой.

Ollama позволяет запускать большие языковые модели (LLM) локально с минимальной настройкой. Поддерживает модели вроде LLaMA, Mistral и другие open-weight альтернативы GPT, так что можно работать с ИИ прямо на своём компьютере без отправки данных в облако.

Если вы работаете с облачными хранилищами или SFTP, WinSCP (Windows) и ForkLift (macOS) — отличные клиенты с двухпанельным управлением файлами, синхронизацией и автоматизацией. На Mac также популярны Commander One и Transmit — у них есть встроенные подключения к удалённым и облачным путям.

Безопасность

И Windows, и macOS сегодня предлагают более чем достойную встроенную защиту. С защитой в реальном времени, интеграцией с файерволом и биометрией вроде Windows Hello и Touch ID. Для обычных пользователей, которые соблюдают гигиену безопасности: не скачивают сомнительное ПО, используют менеджеры паролей и включают 2FA — встроенной защиты часто хватает.

Для продвинутых пользователей есть дополнительные варианты.

Отличное первое дополнение — Malwarebytes. Это давний фаворит в обнаружении и удалении malware, adware и руткитов; бесплатная версия по-прежнему хороша для ручных сканов. В платной — защита в реальном времени без ощутимой просадки производительности.

Если не хочется ставить традиционный антивирус, есть достойные альтернативы. Emsisoft Emergency Kit — мощный портативный сканер, который можно запускать с флешки: идеально для редких глубоких сканов или лечения заражённых систем без установки чего-либо. Просто подключаете, когда нужно.

Ещё один отличный инструмент — VirusTotal: бесплатный веб-сервис, который проверяет файлы и URL через десятки антивирусных движков. Прежде чем открывать подозрительную загрузку, можно залить файл на VirusTotal.com или использовать их расширение для браузера, чтобы проверять ссылки в реальном времени. Быстро, просто и удобно для осторожных пользователей.

Мы не поклонники установки антивирусов на каждый компьютер и не полностью в курсе, какие сейчас показывают лучшие результаты. Тем не менее, AV-Test давно и регулярно оценивает популярные решения, поэтому советуем смотреть их свежие отчёты. В текущем списке высокооценённых — Avast, BitDefender, ESET и другие; многие из них предлагают бесплатные версии для пробы.

Удалённый доступ и вспомогательные утилиты

RustDesk стал современным, ориентированным на приватность аналогом TeamViewer. Он с открытым исходным кодом, быстрый и работает кроссплатформенно.

Тем, кому нужны более устоявшиеся коммерческие решения, подойдёт AnyDesk, который остаётся лёгким и надёжным вариантом для личного и командного использования.

Превращение смартфона в пульт дистанционного управления компьютером бывает невероятно удобно — будь то презентации, потоковое видео или просто навигация с дивана.

Remote Mouse — простой и эффективный способ эмулировать мышь и клавиатуру с телефона. Для более продвинутых сценариев можно использовать приложения вроде Unified Remote.

Редактирование изображений и видео

• Профессиональный видеомонтаж: DaVinci Resolve
• Простой видеомонтаж: CapCut
• Редакторы изображений: GIMP, PhotoDemon, Pixelmator Pro
• Бесплатное улучшение изображений: Upscayl
• RAW-редактирование: RawTherapee
• Видеоконвертация: HandBrake

Если вам нужен бесплатный инструмент для редактирования изображений, GIMP — один из самых мощных вариантов. Он предоставляет профессиональные возможности, такие как слои, маски и настраиваемые плагины, что делает его идеальным для продвинутых пользователей. Если вы ищете более лёгкий редактор с чистым интерфейсом, стоит обратить внимание на PhotoDemon. Он работает как портативное приложение на Windows, поддерживает слои и редактирование — отличный выбор для быстрых правок или ретуши.

Если вы хотите увеличивать разрешение изображений без потери качества, Upscayl — мощный и бесплатный инструмент для апскейла. Он кроссплатформенный, и по нашим тестам показывает результаты на уровне платных решений вроде Topaz.

Для векторной графики — логотипы, иллюстрации — Inkscape является достойным open-source вариантом с полной поддержкой редактирования SVG. Krita — ещё один отличный бесплатный инструмент, особенно подходящий для цифровой живописи и художественного творчества.

Для редактирования RAW-фотографий, Darktable и RawTherapee — два высококлассных open-source аналога Adobe Lightroom. Их широко используют фотографы, которым нужна работа с изображениями без подписки.

Для простых GIF-анимаций ScreenToGif — удобная утилита, мгновенно записывающая область экрана и экспортирующая в GIF или другие форматы с оверлеями.

Среди платных фоторедакторов Adobe Photoshop остаётся лидером, но для macOS есть Pixelmator Pro — мощное приложение с разовой оплатой, а Affinity Photo предлагает профессиональные возможности по более доступной цене.

Видеомонтаж и конвертация

DaVinci Resolve считается лучшим бесплатным профессиональным ПО. Его используют и энтузиасты, и профессионалы — от простого тримминга до цветокоррекции и сложного постпродакшена.

Shotcut и Kdenlive — тоже сильные бесплатные варианты, предлагают более простой фукнционал с хорошим набором функций для новичков и продвинутых пользователей. CapCut, изначально мобильное приложение, теперь доступен на десктопе — идеально подходит для быстрых монтажей и роликов для соцсетей.

Для пользователей macOS iMovie предустановлен и остаётся надёжным вариантом для базовых видео. Если вам нужно просто конвертировать или сжимать видео в современные форматы, HandBrake — проверенное бесплатное решение с поддержкой и вариацией входных и выходных форматов.

Тем, кто ищет топовый профессиональный монтаж, подойдут Adobe Premiere Pro и Final Cut Pro, но там есть дорогая подписка и более высокий порог входа.

Коммуникации и совместная работа

• Для повседневной связи: WhatsApp, Messenger и Zoom, если у вас нет FaceTime
• Для приватности: Signal
• Для работы: Slack, Teams
• Для игр и общения: Discord

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

Для личной переписки WhatsApp и Facebook Messenger остаются самыми массовыми платформами по всему миру. У них есть десктопные клиенты и встроенное сквозное шифрование по умолчанию. Telegram также крайне популярен благодаря синхронизации между устройствами и поддержке крупных чатов. Пользователи Apple продолжают активно использовать iMessage для приватного, шифрованного общения в экосистеме Apple.

Из видеоконференций Zoom остаётся одним из лидеров для групповых звонков и онлайн-ивентов, предлагая локальные записи, демонстрацию экрана и комнаты (breakout rooms). Однако бесплатный тариф ограничивает 1:1 звонки 40 минутами, если не перейти на платный план. Zoom поддерживает сквозное шифрование, но при включении E2EE отключаются некоторые функции вроде облачной записи и комнат.

Google Meet — отличный браузерный аналог без необходимости установки, который заметно улучшился по качеству и удобству использования. Многие компании применяют Meet в ежедневной работе и гибридных форматах. Если ваша организация использует Microsoft 365, скорее всего, вы работаете в Microsoft Teams, который уже заменил Skype на корпоративном уровне. Teams поддерживает большие созвоны, обмен файлами и глубоко интегрирован с Office. Сквозное шифрование доступно, но только для 1:1 звонков.

FaceTime по-прежнему отличный для пользователей Apple, и благодаря новым обновлениям к звонку теперь могут присоединяться и пользователи Android/Windows по ссылке через браузер.

Когда приватность критична, Signal — один из лучших вариантов. Разработан некоммерческой организацией, бесплатен, open-source, без рекламы, использует надёжное сквозное шифрование для сообщений и звонков.

Для рабочих коммуникаций Slack и Teams продолжают использоваться в бизнес-среде. Бесплатный тариф Slack ограничивает историю 90 днями и звонки, но остаётся любимцем стартапов и малых команд благодаря интеграциям и ботам. Cisco Webex — также крепкий вариант, особенно популярен в корпоративной среде.

Если вы работаете с креативными командами, сообществами или геймерами, Discord стал явным лидером. Изначально созданный для игр, он превратился в полноценную коллаборативную платформу с текстом, голосом и видео, стримингом экрана и ботами для автоматизации. Многие комьюнити — и даже IT-компании — используют Discord как основной рабочий инструмент.

Для внутриигрового голосового чата TeamSpeak остаётся олдскульным достойным вариантом: можно использовать анонимно и получать полный контроль над сервером. Встроенный чат Steam лучше, чем раньше, и помогает в игровой координации, но большинство всё же выбирает Discord.

Гейминг, моддинг и стриминг

• Игровые платформы: Steam, Epic Games, EA App, Ubisoft, GOG
• Последние драйверы для GPU: Nvidia GeForce, AMD Radeon, Intel Arc
• Стриминг: OBS Studio

Steam остаётся центром PC-игр. Это не только магазин, но и социальная платформа, лаунчер и площадка с модами, облачными сохранениями и встроенным стримингом. Регулярные распродажи, поддержка контроллеров и сообщества делают его обязательным для любого PC-геймера.

Не менее важно установить Epic Games Store. Хотя библиотека меньше, он регулярно раздаёт бесплатные игры, доступные любому с аккаунтом Epic. Это также must-have, если вы играете в Fortnite.

Помните: не все издатели размещают игры на Steam или Epic. Для тайтлов EA понадобится EA App (ранее Origin), для Ubisoft — Ubisoft Connect, для Blizzard/Activision — Battle.net, а GOG Galaxy не только предлагает DRM-free классику, но и может агрегировать игры из других лаунчеров.

Некоторые сверхпопулярные игры распространяются отдельно: Minecraft (через Minecraft.net или Microsoft Store), Roblox, League of Legends и Valorant (через лаунчер Riot Games). Если вы новичок и ищете что-то лёгкое, можно начать с free-to-play тайтлов или классики вроде Brutal Chess или GZDoom.

Если вы играете с геймпадом, Windows поддерживает Xbox-контроллеры из коробки. PlayStation-контроллеры теперь тоже отлично работают: Steam через Steam Input поддерживает DualShock 4 и DualSense практически во всех играх. При необходимости глубокой кастомизации можно использовать DS4Windows, но большинству хватает возможностей Steam.

Если вас интересует моддинг, хороший менеджер модов время в этой жизни:

• Mod Organizer 2 — лучший для RPG Bethesda (Skyrim, Fallout).
• Vortex (от Nexus Mods) — дружелюбный к новичкам и поддерживает широкий перечень игр.

Для записи геймплея или стриминга Nvidia ShadowPlay и AMD Radeon ReLive подходят для простых задач. Но для стриминга с вебкой, сценами, оверлеями или многосценовым продакшеном OBS Studio — безальтернативный лидер. Он бесплатный, open-source и подходит как новичкам, так и про-стримерам (Twitch, YouTube, Kick и т.д.). SignalRGB помогает синхронизировать весь RGB-зоопарк и задавать динамические эффекты.

Мониторинг железа и разгон

• Мониторинг: CPU-Z, HWMonitor, HWiNFO64
• Настройка и разгон: Afterburner, FanControl, ThrottleStop, SignalRGB

Одно из первых дел, которое стоит сделать после сборки ПК — убедиться, что компоненты соответствуют ожиданиям и работают корректно. К счастью, существует много инструментов, позволяющих мониторить, тестировать и настраивать железо.

Начать стоит с CPU-Z — классического бесплатного инструмента, показывающего информацию о CPU, материнской плате, оперативной памяти и других компонентах. Он также умеет запускать простой стресс-тест и бенчмарк для проверки стабильности.

Для более широкого мониторинга HWMonitor показывает температуры, напряжения и скорости вентиляторов в реальном времени. Если нужно ещё глубже и с более гибким интерфейсом — HWiNFO64 считается одним из лучших: поддерживает логирование датчиков и интеграцию с оверлеями (например, RTSS или Rainmeter).

Чтобы проверить хранилище, CrystalDiskMark измеряет скорость чтения/записи SSD и HDD — это помогает понять, соответствует ли диск заявленным характеристикам. Глубже оценить здоровье накопителя можно в Hard Disk Sentinel, который анализирует SMART-данные, оценивает срок службы и предлагает ограниченный ремонт.

С точки зрения охлаждения, всё больше геймеров используют утилиты для настройки вентиляторов. FanControl — актуальный бесплатный фаворит: поддерживает сложные кривые оборотов, привязку к датчикам, и совместим с большинством современных материнских плат. На Mac одной из лучших утилит остаётся Macs Fan Control.

Для настройки видеокарт долгое время стандартом был MSI Afterburner — для разгона, настройки вентиляторов и мониторинга с RTSS-оверлеем. Однако из-за замедления обновлений многие сегодня используют встроенные утилиты от Nvidia (GeForce Experience/Control Panel) и AMD (Adrenalin Software).

Если вы меняете видеокарту или подозреваете проблемы с драйверами, обязательно используйте Display Driver Uninstaller (DDU) — он полностью очищает систему от старых драйверов перед переустановкой.

Если вы играете на ноутбуке или хотите снизить нагрев и повысить автономность, ThrottleStop остаётся одним из лучших инструментов для андервольта CPU и настройки энергопрофилей.

Тем, кто серьёзно подошёл к разгону CPU и GPU, пригодятся фирменные инструменты вроде Intel XTU (для Intel) и AMD Ryzen Master — они дают контроль над частотами, напряжениями и лимитами мощности.

Управление файлами

• Поиск больших файлов: SpaceSniffer, WizTree, Disk Drill (macOS)
• Поиск дубликатов: dupeGuru
• Архивы и ZIP: PeaZip, The Unarchiver
• Очистка: BCUninstaller, CCleaner Portable, AppCleaner (macOS)

Чтобы грамотно управлять файлами и освобождать место, нужно понимать, что именно занимает пространство. На Windows популярны WinDirStat и WizTree — быстрые бесплатные инструменты для визуализации диска. SpaceSniffer предоставляет динамическую схему.

На macOS — GrandPerspective и Disk Drill предлагают аналогичный функционал, а DaisyDisk — один из самых красивых платных вариантов с молниеносным сканированием.

Если дубликаты засоряют диск, dupeGuru (open-source) отлично справляется с поиском повторяющихся изображений и музыки, даже слегка изменённых.

Для пакетного переименования файлов (например, фоточек с камеры) существует гибкий Bulk Rename Utility. Если нужно что-то попроще: PowerRename из PowerToys (Windows) или встроенный инструмент в Finder (macOS) подходят большинству.

Встроенный File Explorer в Windows недавно получил вкладки и стал удобнее, но Files (open-source) — современная альтернатива с улучшенным UX. Кто-то ещё пользуется Total Commander или Directory Opus, благодаря расширяемости и скриптам, хотя новичкам они кажутся устаревшими. Для просмотра изображений по-прежнему незаменим IrfanView.

Для работы с архивами, если не устраивает встроенный ZIP-менеджер Windows, скачайте 7-Zip или PeaZip. На Mac лучшим бесплатным инструментом остаётся The Unarchiver.

Для очистки системы важно выбирать надёжные утилиты. На Windows, BCUninstaller (Bulk Crap Uninstaller) — один из самых проверенных для удаления программ и их хвостов. BleachBit и Wise Disk Cleaner — безопасные альтернативы CCleaner (лучше использовать Portable-версию, так как стационарная испортила репутацию). На Mac AppCleaner всё ещё любим за полное удаление приложений без мусора.

Если вы организуете большую библиотеку медиа, стоит взглянуть на open-source TagSpaces, позволяющий тегировать файлы локально, без облака.

Облачное хранилище и резервное копирование

• Простая синхронизация: Dropbox, Google Drive
• Фото между устройствами: Apple iCloud, Google Photos
• Приватность: pCloud, Proton Drive, Internxt
• Полные бэкапы: Backblaze, IDrive

Базовое облачное хранилище

Dropbox — один из самых простых в использовании, хотя бесплатных 2 ГБ мало.

Google Drive — 15 ГБ бесплатно, используется Gmail, Docs и Photos. Идеален для Android.

OneDrive — идёт в комплекте с Windows и Microsoft 365. 1 ТБ включён в большинство Office-планов. Хотя по скорости и интерфейсу уступает Dropbox/Google.

iCloud Drive — лучший выбор для пользователей Apple, глубокая интеграция с macOS/iOS. Бесплатно 5 ГБ, далее по планам до 2 ТБ.

Proton Drive — шифрованная альтернатива от создателей ProtonMail.

Фото и видео

На macOS приложение Photos автоматически создаёт альбомы по людям и локациям, синхронизирует всё через iCloud.

На Windows мы часто рекомендуем Google Photos, который предлагает аналогичный набор функций и автоматизацию. Для пользователей Android — это стандарт по умолчанию. Да, раньше было безлимитно, теперь фото занимают общее место Google Drive (15 ГБ), которое быстро заканчивается.

Полные бэкапы

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

Backblaze — топ в этой категории: фиксированная цена (~$8/месяц за устройство), безлимитное хранилище, минимум настроек: установил и забыл.

IDrive — более контролируемый вариант, поддерживает несколько устройств, внешние диски и версионность файлов.

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

Профессионалам — Acronis Cyber Protect: клон дисков, анти-вымогатель, гибридное облако.

Для особо чувствительных данных

Если вы храните личные финансовые документы или медицинские сведения, стоит выбрать end-to-end решений.

pCloud предлагает клиентское шифрование (через платный «Crypto»). Даже при взломе аккаунта файлы не расшифруются без ключа.

Proton Drive — аналогичный подход, с прозрачностью open-source.

Прочие полезные инструменты, не вошедшие в другие разделы

Google Earth — для любителей карт и планировки.

qBittorrent — лучший torrent-клиент: чистый, без рекламы, с поиском. Альтернатива — легковесный Transmission или кастомизируемый Deluge.

iMazing — must-have для владельцев iPhone: резервные копии, экспорт медиа, проверка батареи, конвертация HEIC.

AirDroid — аналог для Android: управление файлам, уведомления, SMS с ПК.

Rufus — лидер по созданию загрузочных USB-дисков для Windows/Linux.

Open Shell — возвращает классическое меню «Пуск» в стиле Windows 7.

Stretchly — напоминает делать перерывы — полезно удалёнщикам и фрилансерам.

AutoHotkey — скриптовый движок для Windows: переназначение клавиш, макросы, автоматизация.

VPN: бесплатные — ProtonVPN, Windscribe, TunnelBear (с лимитом). Платные — ProtonVPN, NordVPN.

Calibre — лучшее бесплатное решение для чтения, организации и конвертации e-book (EPUB, MOBI, PDF и др.).

Заключение

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

Несколько советов напоследок:

1. Не захламляйте систему. Устанавливайте только то, что действительно используете. Чем меньше фоновых процессов — тем быстрее работает компьютер.
2. Следите за обновлениями. Большинство программ обновляются автоматически, но некоторые требуют ручного апдейта. Свежие версии — это не только новые функции, но и закрытые уязвимости.
3. Делайте резервные копии. Никакие утилиты не спасут от отказа жёсткого диска. Регулярный бэкап на внешний носитель или в облако — обязательная практика.
4. Экспериментируйте. Попробуйте несколько браузеров, редакторов, плееров. То, что подходит большинству, может не подойти именно вам.
5. Читайте отзывы. Перед установкой незнакомого приложения загляните на форумы или Reddit. Сообщество быстро выявляет проблемы и подводные камни.

Теперь ваш компьютер готов к работе, учёбе, развлечениям — и чему угодно ещё. Главное — не забывайте, что инструменты важны, но ещё важнее то, как вы их используете. Удачи!