В индустрии давно используются системы контроля версий. Они помогают команде совместно работать над кодом, позволяют отследить изменения и при необходимости откатиться до рабочей версии. Помимо кода там можно хранить конфигурации и манифесты, спецификации и документацию. Короче, Всё-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 и спрашивает: «как у нас устроено вот это». Или сам правит пару строк. Выходит общая база знаний, которую каждый читает и самое главное легко обновляет. Самый дешёвый способ держать знания команды живыми. А как у вас устроены общие знания команд или все по старинке ?