По мере расширения использования ИИ-агентов и вайбкодинга всё чаще возникает вопрос: как, добавляя новый функционал, не сломать то, что уже работает?
Ответ на этот вопрос был придуман ещё задолго до появления ИИ-агентов, потому что человек иной раз способен накосячить хуже любого ИИ-агента.
Чтобы иметь возможность откатиться – необходимо понимать куда откатываться, на какое состояние кода. И по хорошему бы иметь удобную систему контроля состояний, или же систему контроля версий для кода.
От самых базовых "сохранить –> откатиться" мы постепенно эволюционировали до продвинутых инструментов контроля версий. Глобально системы контроля версий можно поделить на три типа:
Локальная система контроля версий. Самый простой и базовый уровень. Автоматизированно сохраняем версии файлов, храним историю локально
Централизованная система контроля версий. Есть точка единой истины – сервер, куда летят все изменения. У разработчиков локально хранится рабочая копия, а вся история изменений находится на сервере. Без подключения к серверу полноценная работа с историей невозможна.
Распределённая система контроля версий. Основной принцип – децентрализация. У каждого разработчика есть все данные, вся история, все версии хранятся везде и сразу. Нет единой точки отказа. Можно проводить локально манипуляции и откатываться к нужному состоянию в любой момент времени
На данный момент, распределение использования примерно равно 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 "[email protected]" 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 после каждых значимых изменений. Я всё же рекомендую перед каждым коммитом просматривать изменения вручную, как и то, что ничего из старого функционала не сломалось
Отвечая на вопрос из начала статьи – лучшее, что вы можете сделать, чтобы не сломать ваш работающий проект очередным промптом – это освоить систему контроля версий. Потратив полчаса времени сейчас, можно сэкономить десятки часов в будущем
Источник


