Как пользоваться Git для приложения, созданного с помощью ИИ

Чтобы использовать Git с приложением, созданным ИИ, подключите проект к Git-репозиторию, делайте коммит после каждого рабочего изменения, пишите однострочное сообщение о том, что изменилось, и храните секреты вне репозитория с помощью .gitignore. Используйте ветку для любой рискованной работы, делайте pull перед следующим запросом, если кто-то другой изменил код, а когда ИИ что-то сломает, возвращайтесь к последнему рабочему коммиту, а не продолжайте накладывать запросы поверх поломки.

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

Почему Git важнее при работе с ИИ

ИИ может изменить двадцать файлов за один ход. Это быстро, но и означает, что один запрос может незаметно сломать то, что вчера работало. Git даёт вам:

• Путь назад. Любую зафиксированную версию можно восстановить.
• Запись изменений. Вы видите, какие файлы и строки затронул каждый запрос.
• Копию вне конструктора. Ваш код хранится там, где им управляете вы.
• Стандартную передачу проекта. Любой разработчик, хостинг или инструмент может работать с Git-репозиторием.

Шаг 1: Подключите репозиторий

Создайте репозиторий (обычно приватный) на GitHub или похожем сервисе и подключите к нему проект. Большинство конструкторов приложений с ИИ, которые поддерживают Git, делают это на странице настроек кнопкой «Connect GitHub». Если в вашем нет такой функции, можно экспортировать код и отправить его самостоятельно или один раз попросить разработчика настроить это.

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

Проверь файл .gitignore. Убедись, что в нём исключены файлы .env, node_modules, папки с результатами сборки и любые файлы с секретами. Скажи мне, что ты добавил.

Шаг 2: Коммитьте после каждого рабочего изменения

Коммит — это сохранённый снимок с сообщением. Важнее всего привычка: коммитьте, когда что-то работает, до того как запросите следующее.

1. Запросите одно изменение.
2. Проверьте его в предпросмотре.
3. Если всё работает, сделайте коммит (или синхронизацию) с сообщением.
4. Затем переходите дальше.

Маленькие коммиты означают, что когда что-то сломается, вы знаете, какое изменение это вызвало, и отмена не затронет остальную работу.

Шаг 3: Пишите сообщения, которые понятны и позже

Хорошее сообщение в одной строке говорит, что изменилось и зачем:

• Хорошо: Добавить экспорт заказов в CSV на странице заказов
• Хорошо: Исправить отклонение времени записи после 18:00 в форме бронирования
• Бесполезно: update, changes, fix stuff

Можно попросить ИИ написать их за вас:

Кратко опиши изменения с последнего коммита одной строкой, начни с глагола, не длиннее 70 символов.

Шаг 4: Используйте ветки для рискованной работы

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

Используйте ветку, когда:

• Изменение большое (редизайн, новый платёжный процесс, изменение базы данных).
• Над тем же приложением работает кто-то ещё.
• Вы хотите, чтобы кто-то проверил изменение до публикации.

Когда работа готова и протестирована, её сливают (merge) обратно в основную ветку. На GitHub это обычно делается через pull request — страницу с изменениями для проверки. Если ваш конструктор синхронизирует только одну ветку, управлять ветками на стороне GitHub может разработчик.

Шаг 5: Безопасно откатывайте изменения

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

• В конструкторе: используйте контрольную точку или функцию восстановления, если она есть.
• В Git: git revert создаёт новый коммит, который отменяет старый, и сохраняет историю. Это безопасный выбор для кода, который другие могли уже получить через pull.
• Избегайте git push --force в общей ветке, если точно не знаете зачем. Он переписывает историю для всех.

Если не уверены, спросите:

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

Шаг 6: Делайте pull перед запросом

Если разработчик или другой инструмент меняет код на GitHub, конструктор с ИИ не знает об этом, пока вы не загрузите эти изменения командой pull. Запрос на старом коде приводит к конфликтам и потере работы.

• Делайте pull в начале каждой сессии.
• Договоритесь, кто что редактирует, и не допускайте, чтобы обе стороны одновременно меняли одни и те же файлы.
• Если возник конфликт слияния (два изменения одних и тех же строк), попросите разработчика или ИИ разрешить его и объяснить выбор.

Примеры запросов

Прежде чем начнём: что изменилось в репозитории с моей последней сессии? Кратко перечисли коммиты.

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

Проверь, что в Git не отслеживаются API-ключи, пароли или файлы .env, в том числе в прошлых коммитах. Назови только имена файлов, без значений.

Частые ошибки

• Коммит секретов. Как только ключ попал в историю Git, он раскрыт, даже если файл потом удалили. Перевыпустите его.
• Один огромный коммит в неделю. Одно изменение нельзя отменить, не отменив все остальные.
• Сообщения вроде «update». История становится бесполезной для поиска того, что сломалось.
• Запросы на устаревшем коде. Сделайте pull первым, если кто-то другой редактирует код.
• Force push для исправления ошибки. Это может стереть чужую работу. Используйте revert.
• Коммит node_modules. Папка огромная, и её всё равно пересоздают из lock-файла.

Чек-лист

• Проект подключён к приватному репозиторию.
• .gitignore исключает .env, node_modules, результаты сборки и секреты.
• Я делаю коммит после каждого рабочего изменения.
• Сообщения коммитов в одной строке говорят, что изменилось.
• Крупные или рискованные изменения идут в отдельной ветке и проходят проверку.
• Я делаю pull перед запросом, если код редактирует кто-то ещё.
• Я откатываю изменения контрольными точками или git revert, а не force push.
• Любой ключ, который когда-либо попадал в коммит, перевыпущен.

Git в Mythex

Mythex сохраняет контрольную точку Git после каждого успешного хода агента, а «Вернуть к этой точке» откатывает проект к ней — это та самая отмена на стороне конструктора, о которой говорится в шаге 5. См. Итеративная работа без пересборки.

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

Вопросы