Како да користите Git со апликација изградена со AI

За да користите Git со апликација направена со AI, поврзете го проектот со Git репозиториум, направете commit по секоја исправна промена, напишете една линија со порака што вели што се променило и чувајте ги тајните податоци надвор со .gitignore. Користете гранка за секоја ризична работа, направете pull пред повторно да испратите prompt ако некој друг ја променил кодот, а кога AI ќе расипе нешто, вратете се на последниот добар commit наместо да пишувате нови prompts врз нередот.

Git е контрола на верзии: историја на секоја зачувана верзија на вашиот код. GitHub е веб-страница што ги чува Git репозиториумите на интернет. Ако се нови за вас, почнете со што е GitHub. Овој водич е за навиките што го прават Git корисен кога AI пишува најголемиот дел од кодот.

Зошто Git е уште поважен со AI

AI може да промени дваесет датотеки во еден одговор. Тоа е брзо, но значи и дека еден prompt тивко може да расипе нешто што вчера сте го тестирале. Git ви дава:

• Враќање назад. Секоја commit-ана верзија може да се врати.
• Запис за промените. Можете точно да видите кои датотеки и редови ги допрел еден prompt.
• Копија надвор од градителот. Вашиот код е на место што го контролирате вие.
• Стандардно предавање. Секој developer, хост или алатка може да работи од Git репозиториум.

Чекор 1: Поврзете репозиториум

Создајте репозиториум (обично приватен) на GitHub или слична услуга и поврзете го вашиот проект со него. Повеќето градители на апликации со AI што поддржуваат Git го прават ова преку страница со поставки и копче „Connect GitHub“. Ако вашиот не го поддржува тоа, можете да го извезете кодот и сами да го пуштите (push), или да замолите developer еднаш да го постави.

Пред првиот push, проверете дека репозиториумот ги игнорира работите што не треба да бидат таму:

Проверете ја датотеката .gitignore. Осигурајте се дека ги исклучува .env датотеките, node_modules, папките со build излез и секоја датотека со тајни податоци. Кажи ми што додаде.

Чекор 2: Направете commit по секоја исправна промена

Commit е зачувана слика на состојбата со порака. Навиката што е важна: направете commit кога нешто работи, пред да побарате следното нешто.

1. Побарајте една промена.
2. Проверете ја во прегледот.
3. Ако работи, направете commit (или синхронизација) со порака.
4. Потоа продолжете.

Мали commit-и значат дека кога нешто ќе се расипе, знаете која промена го направила тоа, а поништувањето на неа не фрла други ваши промени.

Чекор 3: Пишувајте пораки што ќе ги разберете подоцна

Добрата порака вели што се променило и зошто, во една линија:

• Добро: Додади CSV извоз на страницата со нарачки
• Добро: Поправи формата за резервации што ги отфрла термините после 18ч
• Не е корисно: update, changes, fix stuff

Можете AI да ги напише:

Резимирај ги промените од последниот commit во една линија што започнува со глагол, до 70 знаци.

Чекор 4: Користете гранки за ризична работа

Гранката е посебна линија на работа. Можете нешто да пробате на гранка, а ако не успее, да ја напуштите без да го допрете главниот верзија.

Користете гранка кога:

• Промената е голема (редизајн, нов тек на плаќање, промена во базата).
• Некој друг работи на истата апликација.
• Сакате некој да ја прегледа промената пред да оди во живо.

Кога работата е готова и тестирана, се спојува назад во главната гранка. На GitHub тоа обично се прави преку pull request, страница што ги прикажува промените за преглед. Ако вашиот градител синхронизира само една гранка, developer може да управува со гранките од GitHub страната.

Чекор 5: Безбедно поништување

Кога prompt ќе ја расипе апликацијата, одолејте на желбата да пишувате уште пет prompts врз неа. Вратете се на последната добра верзија и пробајте попрецизен prompt.

• Во градителот: користете ја неговата контролна точка или функција за враќање, ако ја има.
• Во Git: git revert создава нов commit што ја поништува стара промена, со што историјата останува цела. Тоа е безбедниот избор за код што други можеби го превзеле.
• Избегнувајте git push --force на заедничка гранка, освен ако точно не знаете зошто. Тоа ја пишува историјата одново за сите.

Ако не сте сигурни, прашајте:

Последната промена ја расипа страницата за најава. Покажи ми кои датотеки ги променила во однос на претходниот commit и објасни што направила секоја промена. Не менувај ништо уште.

Чекор 6: Направете pull пред да испратите prompt

Ако developer или друга алатка ја промени кодот на GitHub, градителот со AI не знае за тоа додека не ги превземете промените со pull. Испраќање prompt врз стар код предизвикува конфликти и загубена работа.

• Направете pull на почетокот на секоја сесија.
• Договорете се кој што уредува и избегнувајте двајцата истовремено да ги уредуваат истите датотеки.
• Ако добиете merge конфликт (две промени на истите редови), замолете developer-от или AI да го реши и да објасни зошто избрал така.

Примери на prompts

Пред да почнеме: што се променило во репозиториумот од мојата последна сесија? Резимирај ги commit-ите.

Направи ја следната промена сама: додади копче „Duplicate“ на секоја фактура. Не менувај ништо друго, за да можам да ја commit-нам посебно.

Провери дека ниту еден API клуч, лозинка или .env датотека не е следена во Git, вклучително и во минатите commit-и. Пријави само имиња на датотеки, без вредности.

Чести грешки

• Commit-ирање на тајни податоци. Кога клуч ќе влезе во Git историјата, тој е изложен, дури и ако подоцна ја избришете датотеката. Сменете го клучот.
• Еден огромен commit неделно. Не можете да поништите една промена без да ги поништите сите.
• Пораки како „update“. Историјата станува бескорисна за наоѓање што се расипало.
• Prompt врз застарен код. Направете pull прво кога некој друг уредува.
• Force push за поправање грешка. Може да избрише туѓа работа. Наместо тоа користете revert.
• Commit-ирање на node_modules. Е огромна и секогаш се создава повторно од lock датотеката.

Листа за проверка

• Проектот е поврзан со приватен репозиториум.
• .gitignore ги исклучува .env, node_modules, build излезот и тајните податоци.
• Правам commit по секоја исправна промена.
• Пораките за commit вршат што се променило, во една линија.
• Големите или ризичните промени одат на гранка и се прегледуваат.
• Направам pull пред prompt кога некој друг уредува кодот.
• Поништувам со контролни точки или git revert, не со force push.
• Секој клуч што некогаш бил committed е сменет.

Git во Mythex

Mythex зачувува git контролна точка после секој успешен агентски чекор, а Revert to this point го враќа проектот во таа состојба — поништувањето од страна на градителот опишано во чекор 5. Видете Iterate without rebuilding.

Во Pro, GitHub sync поврзува репозиториум од поставките на проектот, за да можете да пушате и да превземате од него, а export го превзема проектот со исклучени тајни податоци и node_modules. Видете GitHub, export, and import. Поврзувањето на GitHub пред да му предадете проект на developer го прави предавањето многу полесно — видете како да работите со developer на апликација направена со AI и како да извезете и самостојно хостирате апликација направена со AI.

Прашања