Як користуватися Git із застосунком, створеним за допомогою ШІ

Щоб користуватися Git із застосунком, створеним ШІ, під'єднайте проєкт до Git-репозиторію, робіть коміт після кожної робочої зміни, пишіть одним рядком, що саме змінилося, і тримайте секрети поза репозиторієм за допомогою .gitignore. Для ризикованих змін використовуйте окрему гілку, перед новим запитом оновлюйте код, якщо хтось інший змінив його, а коли ШІ щось зламав, поверніться до останнього робочого коміту, а не пишіть нові запити поверх безладу.

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: використовуйте гілки для ризикованої роботи

Гілка — це окрема лінія роботи. Ви можете щось спробувати в гілці, а якщо не вийде, відмовитися від неї, не торкаючись основної версії.

Використовуйте гілку, якщо:

• Зміна велика (перероблений дизайн, новий потік оплати, зміна бази даних).
• Над тим самим застосунком працює ще хтось.
• Ви хочете, щоб зміну перевірили перед публікацією.

Коли робота готова й перевірена, її зливають назад в основну гілку. На GitHub це зазвичай відбувається через pull request — сторінку, де видно зміни для перегляду. Якщо ваш конструктор синхронізує лише одну гілку, керувати гілками на боці GitHub може розробник.

Крок 5: відкочуйте безпечно

Коли запит ламає застосунок, не поспішайте надсилати ще п'ять запитів поверх нього. Поверніться до останньої робочої версії та спробуйте чіткіший запит.

• У конструкторі: скористайтеся його функцією чекпоїнтів або відновлення, якщо вона є.
• У Git: git revert створює новий коміт, який скасовує старий, і зберігає історію. Це безпечний вибір для коду, який інші могли вже завантажити.
• Уникайте git push --force на спільній гілці, якщо точно не знаєте навіщо. Ця команда переписує історію для всіх.

Якщо сумніваєтеся, запитайте:

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

Крок 6: оновлюйте код перед запитом

Якщо розробник або інший інструмент змінює код на GitHub, конструктор ШІ цього не знає, доки ви не завантажите ці зміни. Запити на старому коді призводять до конфліктів і втрати роботи.

• На початку кожної сесії завантажуйте останні зміни.
• Домовтеся, хто що редагує, і не допускайте, щоб дві сторони одночасно змінювали ті самі файли.
• Якщо виник конфлікт злиття (дві зміни тих самих рядків), попросіть розробника або ШІ його вирішити та пояснити вибір.

Приклади запитів

Перш ніж почати: що змінилося в репозиторії з моєї останньої сесії? Підсумуй коміти.

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

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

Поширені помилки

• Коміт секретів. Щойно ключ потрапив в історію Git, він розкритий, навіть якщо ви видалили файл. Замініть його.
• Один великий коміт на тиждень. Ви не зможете скасувати одну зміну, не скасувавши всі.
• Повідомлення на кшталт «update». Історія стає марною для пошуку того, що зламалося.
• Запити на застарілому коді. Оновлюйте код перед роботою, якщо над ним працює хтось інший.
• Force-push для виправлення помилки. Це може стерти чужу роботу. Краще скористайтеся revert.
• Коміт node_modules. Ця папка величезна, і її все одно відтворюють із файлу блокування.

Чекліст

• Проєкт під'єднано до приватного репозиторію.
• .gitignore виключає .env, node_modules, папку збірки та секрети.
• Я роблю коміт після кожної робочої зміни.
• Повідомлення комітів одним рядком пояснюють зміну.
• Великі або ризиковані зміни йдуть в окрему гілку та проходять перевірку.
• Я оновлюю код перед запитом, якщо його редагує хтось інший.
• Я відкочую через чекпоїнти або git revert, а не через force-push.
• Будь-який ключ, що колись потрапив у коміт, замінено.

Git у Mythex

Mythex зберігає git-чекпоїнт після кожної успішної відповіді агента, а Revert to this point повертає проєкт до нього — це відкат на боці конструктора, описаний у кроці 5. Див. Iterate without rebuilding.

На тарифі Pro синхронізація з GitHub під'єднує репозиторій у налаштуваннях проєкту, щоб ви могли надсилати та отримувати зміни, а експорт завантажує проєкт без секретів і папки node_modules. Див. GitHub, export, and import. Під'єднання GitHub перед передачею проєкту розробнику значно спрощує передачу — див. як працювати з розробником над застосунком, створеним ШІ і як експортувати та самостійно розгорнути застосунок, створений ШІ.

Запитання