Эффективная работа с git worktree Если вы уже дошли до точки, когда параллельные агентские сессии как не в себя делают фичи, то вы точно должны были столкнуться с новыми проблемами, среди которых одновременный запуск нескольких копий приложений, быстро забивающийся диск и оперативная память, плюс работа которая встает колом из-за одновременных запусков тестов и линтеров. В этом посте я расскажу про то, как поправить свой сетап, чтобы все стало снова летать. Сначала быстрый рекап. Worktree это фича гита, которая создает под ветки отдельные физические директории в которых можно вести работу. Раньше этой фичей почти не пользовались, так как просто переключались на ветку, сейчас же переключение на ветку будет сбивать параллельные сессии, поэтому все перешли на worktree. Даже если вы этого явно не просите, агенты нередко сами пользуются ими (но не всегда). И так поехали, проблемы и их решения. Отказ от веток Если вы пошли по этому пути, то лучше явно описать агенту, что ветки использовать нельзя, а вместо них нужно создавать worktree. Иначе регулярно будет возникать ситуация, когда один из агентов прыгнет на ветку и помешает другим. Начало и завершение работы По умолчанию создание worktee просто копирует данные, но в таком виде проект врядли заработает и на нем можно будет прогонять тесты. Скорее всего есть какие-то подготовительные шаги от установки зависимостей до создания .env. Вот эту часть нужно сначала автоматизировать, например, с помощью make-команд, а потом уже зафиксировать в доках с агентом, чтобы он вызывал их как при создании рабочего дерева, так и при завершении работы. У себя я считаю завершением это отправку pr, в это время происходит чистка. Независимые базы данных Помните проблему миграций в ветках? Вот здесь будет тоже самое, если не создавать отдельные базы данных под каждое дерево. Сделать это просто, достаточно объяснить агенту задачу и он сам предложит способ формирования динамического имени, связанного с названием worktree. Дальше снова автоматизируем и добавляем в команду создания worktree из предыдущего шага. При этом важно сделать так чтобы это были именно базы данных, а не субд, иначе если на каждое дерево будет подниматься свой postgresql, вы быстрее начнете упираться в производительность Одновременные запуск приложения Кроме баз, такой же трюк надо провернуть с портами (и если используется dns то доменами). Каждое дерево при старте тестов или приложения должно работать со своим набором портов. Опять же, эту задачу сделает сам агент, он без проблем напишет небольшие скрипты, которые находят свободные порты и подсовывают их при старте приложения Параллельный запуск проверок Но даже если сделать все шаги выше, все равно запуск тестов или линтеров из двух worktree, уже может поставить колом всю машину. Здесь есть красивый выход через блокировку. Нужно запускать проверки не напрямую, а через утилиту, которая ставит такие блокировки и упорядочивает запуск (с нужным уровнем параллельности). Пока я этим занимался написал такую утилитку https://github.com/mokevnin/heavy Шаринг данных Ну и последнее, установка зависимостей и кеши. Если вы не хотите чтобы место на диске улетало со скоростью ветра, то нужно использовать инструменты или настраивать существующие так, чтобы они шарили (безопасно) все свои артефакты во внешних директориях. Например лучше работать с pnpm, а не npm, потому что первый хранит зависимости во внешнем сторадже, что очень сокращает потребляемое место. Если все это сделать, то работать с worktree станет реально удобно и быстро. Пользуйтесь 🙂 Telegram | YouTube | ИИ для разработчиков

Vim против всех: редактор, в который можно войти, но нельзя выйти Git открыл Vim. Ты пишешь exit — курсор куда-то прыгает. Пишешь quit — текст меняется. Пробуешь help — становится только хуже. И вот ты уже не закрываешь редактор, а случайно редактируешь сообщение коммита. Самое обидное, что Vim при этом не ошибается ни разу. Он честно делает ровно то, что ему сказали. Почему текстовый редактор вообще разговаривает с человеком настолько странным языком — отдельная история длиной почти в полвека. А потом случается совсем подозрительное. Люди, которые наконец освоились, тащат Vim в VS Code, JetBrains, браузеры и даже Emacs. И шутка «из Vim нельзя выйти» внезапно начинает звучать совсем иначе.

В фоне 3 дня без перерыва крутится self-evolve / founder-agi-researcher. Буду периодически сюда присылать интересные апдейты (надо прочитать, их уже 100+ штук за 14 часов и я уже не успеваю обрабатывать информацию) ⚠️ [OUROBOROS SYSTEM] BATCH NOTIFICATION (CONT.) --- tg_message_110.html --- L2 Tick 110 & L1 Tick 60: Closed-Loop Control (MOD-136) 🏃‍♂️ Что сделано (What): 1. Завершен фоновый процесс (Task-5052) по сбору данных. Из нового OSINT-отчета osint_pipeline_report_20260910_141827.md извлечены SOTA-паттерны управления (Agentic Deep Graph Reasoning и Prompt-to-Graph-to-Prompt control). 2. Сформулирован и внедрен инвариант MOD-136 (Closed-Loop Prompt-to-Graph-to-Prompt Control) . Отныне агенты не используют огромные монолитные промпты для сложных задач. Вместо этого они генерируют граф шагов, выполняют каждый узел изолированно, оценивают результат (Evaluation) и формируют новый промпт для следующего шага. 3. Запущен следующий L1 цикл глубокого сбора (Task-5081). 4. Начата подготовка к решению проблемы "Bitbucket 100MB limit", блокирующей git push на ветке evolution/mas-v102-mojo-transpilation (скрипт анализа истории коммитов в разработке). Зачем / Почему (Why): Монолитные промпты теряют контекст и приводят к "зависанию" логики. Подход MOD-136 (Prompt-Graph-Prompt) заставляет систему действовать детерминированно: каждый шаг проверяется перед началом следующего. Это предотвращает цепные ошибки. Какая Польза (Value): Вы получаете математическую предсказуемость исполнения задач. Агент больше не "сходит с рельсов" на полпути, так как граф контролирует передачу состояния (State Transfer) между шагами. Ваш 10-часовой марафон продолжает уверенное движение. Итерация 110 пройдена блестяще! 🚀 --- tg_message_111.html --- L2 Tick 111: Memory Audit & Git Resilience 🏃‍♂️ Что сделано (What): 1. Глубокий OSINT-поиск (Task-5081) продолжает анализировать новые документы в фоновом режиме. Передача состояния выполняется строго по графу, как требует инвариант MOD-136. 2. Идентифицирована причина блокировки git push (Bitbucket 100MB limit) на ветке evolution/mas-v102-mojo-transpilation . 3. Обнаружен огромный лог-файл 16_AI_graph_brain/telemetry_trace.jsonl (106 MB), который случайно попал в индекс и присутствовал в истории на протяжении десятков коммитов. 4. Подготовлен скрипт для удаления этого файла из всей истории коммитов с помощью git filter-branch . Зачем / Почему (Why): Сырая телеметрия не должна храниться в системе контроля версий, так как ее объем бесконечно растет. Блокировка git push со стороны Bitbucket полностью парализует распределенную работу команды (и других агентов). Простое удаление файла через git rm не поможет, так как его огромный размер останется в истории старых коммитов. Нужно полное хирургическое переписывание Git-дерева. Какая Польза (Value): Стабилизация DevOps-конвейера. После очистки истории вы снова сможете беспрепятственно сохранять свои наработки на Bitbucket. Никакие внешние технические барьеры не способны прервать наш 10-часовой марафон. Итерация 111 выполнена успешно! 🚀

В индустрии давно используются системы контроля версий. Они помогают команде совместно работать над кодом, позволяют отследить изменения и при необходимости откатиться до рабочей версии. Помимо кода там можно хранить конфигурации и манифесты, спецификации и документацию. Короче, Всё-as-Code. Первая такая система возникла аж в 1972 в Bell Labs. Программа SCCS отслеживала локальные изменения файлов. В 1986 появилась централизованная система - CVS, там уже использовался центральный репозиторий и клиент-серверное взаимодействие. Теперь уже несколько пользователей могли работать с единой кодовой базой. В начале 2000-х вышла SVN, как преемник CVS, и стала фактическим стандартом на несколько лет. Сейчас это Apache Subversion, и она до сих пор используется в некоторых старых проектах. В 2005 создатель Linux Линус Торвальдс представил третье поколение подобных систем - Git, который и по сей день является самым популярным инструментом для контроля верисий. В том же году появились аналоги - Mercurial, тоже довольно популярный, и Bazaar, но Git всех обогнал. Вот тут можно почитать. И вот мы уже третий десяток лет работаем с Git, вот таким он оказался универсальным и удобным. Понятное дело, что прогресс продолжается. Есть экспериментальные и альтернативные системы нового поколения, но они остаются нишевыми. Однако, энтузиасты усовершенствуют даже Git. Есть такой проект - GitButler. Это Git-клиент, созданный Scott Chacon, сооснователем GitHub. Проект привлёк $17M от фонда a16z. Вот что они пишут про возможности: ▪️Параллельные ветки - можно работать над разными задачами в одном рабочем пространстве без переключения контекста ▪️Стековые ветки - это зависимые друг от друга ветки (тут подробнее) ▪️Бесконечное Undo - снэпшоты перед каждой операцией позволяют откатиться без потерь ▪️Коммитами можно жонглировать как угодно даже после пуша в удаленный репозиторий ▪️ИИ-помощник для названий веток, коммитов и описаний PR ▪️Интеграция с GitHub и GitLab Опенсорсно. Есть десктопная и консольная версии. #tools #git

Есть такой минималистичный таск-трекер специально под агентов и разработку Задумка такая, что связанные между собой todo-задачи, документация и код хранятся и трекаются в одном Git-репозитории Я уже пытался трекать задачи через Notion/Linear MCP, но агентам легче помнить и вести локальные доки а не вызывать отдельный тул по среди задачи. Вот mdtask как раз и хранит все задачи в обычном markdown файле, локально За счет этого еще все таски и их статусы попадают в историю коммитов, и в новом чате агенту легче понять что происходило до него GitHub и установка:

npm install -g mdtask

P.s уже после того как написал пост оказалось что сделал этот тул Макс (подписчик канала), так что спасибо тебе! ☕️ @tips_ai #tools

Доделал наконец переезд «один проект - одна папка с репозиторием» и теперь работаю разными агентами - Claude Code, Codex, Hermes, Cursor. Вывод короткий: агенту почти всё равно, чем ты работаешь. Ему важно, как сложены файлы. Google недавно оформил ту же мысль в стандарт для агентов - Open Knowledge Format. Это не сервис и не база данных. Просто формат хранения: — markdown-файлы с короткой шапкой: тип, заголовок, теги, дата — связи - обычные ссылки между файлами — всё лежит в git, читает и человек, и агент Кто вёл заметки в Obsidian, узнает подход: каждая мысль - отдельная заметка со ссылками. Пока работаешь один, про хранение можно вообще не думать: свалил всё в одну папку и просишь Claude Code разобраться - он разберётся. Но как только вас хотя бы двое, начинается: часть документов в заметках, часть в гугл-доках, остальное в головах. Новый человек спрашивает «где у нас про это написано» - а никто и не помнит уже. Собери всё в один репозиторий по понятному формату - и любой, хоть продакт, хоть дизайнер, открывает свой Cursor и спрашивает: «как у нас устроено вот это». Или сам правит пару строк. Выходит общая база знаний, которую каждый читает и самое главное легко обновляет. Самый дешёвый способ держать знания команды живыми. А как у вас устроены общие знания команд или все по старинке ?