По мере расширения использования ИИ-агентов и вайбкодинга всё чаще возникает вопрос: как, добавляя новый функционал, не сломать то, что уже работает?
Ответ на этот вопрос был придуман ещё задолго до появления ИИ-агентов, потому что человек иной раз способен накосячить хуже любого ИИ-агента.
Чтобы иметь возможность откатиться – необходимо понимать куда откатываться, на какое состояние кода. И по хорошему бы иметь удобную систему контроля состояний, или же систему контроля версий для кода.
От самых базовых "сохранить –> откатиться" мы постепенно эволюционировали до продвинутых инструментов контроля версий. Глобально системы контроля версий можно поделить на три типа:
Локальная система контроля версий. Самый простой и базовый уровень. Автоматизированно сохраняем версии файлов, храним историю локально
Централизованная система контроля версий. Есть точка единой истины – сервер, куда летят все изменения. У разработчиков локально хранится рабочая копия, а вся история изменений находится на сервере. Без подключения к серверу полноценная работа с историей невозможна.
Распределённая система контроля версий. Основной принцип – децентрализация. У каждого разработчика есть все данные, вся история, все версии хранятся везде и сразу. Нет единой точки отказа. Можно проводить локально манипуляции и откатываться к нужному состоянию в любой момент времени
На данный момент, распределение использования примерно равно 0 / 5 / 95 %, где локальными системами почти никто не пользуется, централизованные живы только частично за счёт энтерпрайза, и бОльшую часть занимают распределённые системы контроля версий, где самой популярной системой является Git.
В данной статье рассматривать будем только лишь её.
Итак, Git. С чего начать? Для начала, Вам необходимо установить git локально на вашу OC. Затем переходим в папку проекта и создадим пустой репозиторий. Делается это при помощи команды git init.
Репозиторий – это хранилище истории, изменений, списка файлов и директорий.
После инициализации пустого репозитория, нам необходимо создать в корне проекта файл .gitignore и заполнить его теми данными и паттернами, которые мы не желаем видеть в хранилище. Самые типичные примеры – это пароли и секреты, которые хранятся в .env файлах, также все неизменяемые объекты, такие как внешние библиотеки и зависимости, дополнительно в игнор можно добавить Ваши локальные конфиги и настройки окружения.
Самый простой способ понять, что нужно добавлять в .gitignore – это представить, что у вас появился коллега, с которым Вы вместе работаете над проектом. Доступ к каким данным ему не нужен?
После заполнения .gitignore нужно добавить все имеющиеся файлы в индекс git.
Индекс в git – это промежуточная зона, где хранятся те файлы, которые нужно отслеживать на предмет изменений и только для файлов из индекса нужно сохранять состояние.
Добавление всех файлов, которые находятся в проекте можно выполнить при помощи команды git add --all. Таким образом, в индекс попадут все файлы, которые не находились в .gitignore.
После чего, мы можем зафиксировать состояние файлов. Состояние фиксируется при помощи коммита. Коммит можно представить себе как чекпоинт, на который всегда можно откатиться, если что-то пойдёт не так. Коммит можно выполнить как для всех изменений в индексе одновременно, так и только для отдельно взятых файлов, если вы не готовы по части из них фиксировать состояние.
Перед первым коммитом после установки git нужно ввести свои контактные данные. Так как каждый коммит – это изменение, сделанное определённым автором. Фиксируются личные данные при помощи:
git config --global user.email "you@example.com" git config --global user.name "Your Name"
Теперь можем сделать наш первый коммит! git commit -m "My first commit"
После флага -m ставится сообщение, в котором вы описываете, что именно было сделано в текущем изменении, по отношению к предыдущему состоянию
После коммита, сразу же становится доступно несколько очень полезных плюшек. Например, в любой момент можно посмотреть в каких файлах были сделаны изменения, какие файлы были удалены или добавлены после последнего коммита. Сделать это можно командой git status. Также, теперь можно откатываться к предыдущим состояниям и даже сравнивать их между собой
Каждый коммит имеет уникальный хеш – последовательность символов. Чтобы узнать хеш нужного вам коммита можно просмотреть историю – git log, при выполнении отобразится список коммитов, с датой и времени их добавления, а также, с сообщением, которое мы писать при коммите после флага -m.
Чтобы откатиться на предыдущий коммит, можно использовать либо git checkout <COMMIT_HASH>, либо git reset <COMMIT_HASH>. На месте COMMIT_HASH можно вставить хеш нужного коммита. Только надо быть крайне осторожными, при выполнении этих команд, так как при определенных параметрах они могут принудительно сбрасывать состояние вашего проекта, удаляя при эт��м файлы, которых не было на момент прошлого состояния.
Лучше всего руководствоваться официальной документацией для гит. В ней можно подробнее узнать про ветвление, удалённые репозитории, процедуры слияния и т.д.
Для удалённого хранения истории обычно используются Github, Gitlab, или аналогичные сервисы. Но это тема для отдельной статьи
Если вам кажется, что постоянное ручное управление индексированиями и коммитами будет занимать слишком много времени, то тут можно выдохнуть.
Во-первых, все современные IDE в которых ведётся обычно разработка, имеют встроенный UI по работе с гитом. Благодаря нему, запоминание сложных команд превращается в простую последовательность действий, которые требуется выполнить при каждом сохранении состояния
Во-вторых, вы всегда можете переложить управление состояниями в git на ИИ-агента, дав ему соответствующую инструкцию - сохранять состояние в git после каждых значимых изменений. Я всё же рекомендую перед каждым коммитом просматривать изменения вручную, как и то, что ничего из старого функционала не сломалось
Отвечая на вопрос из начала статьи – лучшее, что вы можете сделать, чтобы не сломать ваш работающий проект очередным промптом – это освоить систему контроля версий. Потратив полчаса времени сейчас, можно сэкономить десятки часов в будущем
