Paano Gamitin ang Git sa App na Ginawa ng AI

Para gamitin ang Git sa app na ginawa ng AI, ikonekta ang project sa Git repository, mag-commit pagkatapos ng bawat pagbabagong gumagana, sumulat ng isang linyang mensaheng nagsasabi kung ano ang nagbago, at ilayo ang mga secret gamit ang .gitignore. Gumamit ng branch para sa anumang delikado, mag-pull bago ka magprompt ulit kung may ibang nagbago ng code, at kapag nasira ng AI ang isang bagay, bumalik sa huling gumaganang commit sa halip na magprompt sa ibabaw ng gulo.

Ang Git ay version control: isang history ng bawat naka-save na bersyon ng code mo. Ang GitHub naman ay website na nag-iimbak ng mga Git repository online. Kung bago pa ito sa iyo, magsimula sa ano ang GitHub. Tungkol ang gabay na ito sa mga gawi na nagpapagamit sa Git kapag halos lahat ng code ay sinusulat ng AI.

Bakit mas mahalaga ang Git sa AI

Kayang baguhin ng AI ang dalawampung file sa isang turn. Mabilis iyon, pero ibig sabihin din na ang isang prompt ay maaaring tahimik na makasira ng bagay na gumana kahapon. Binibigyan ka ng Git ng:

• Daan pabalik. Maibabalik ang anumang naka-commit na bersyon.
• Talaan ng mga pagbabago. Makikita mo kung aling mga file at linya ang hinawakan ng isang prompt.
• Kopya sa labas ng builder. Nasa lugar na kontrolado mo ang code mo.
• Pamantayang paraan ng paghahatid. Makakapagtrabaho ang anumang developer, host o tool mula sa Git repository.

Hakbang 1: Ikonekta ang repository

Gumawa ng repository (kadalasang private) sa GitHub o katulad na serbisyo, at ikonekta ang project mo dito. Karamihan sa mga AI app builder na sumusuporta sa Git ay ginagawa ito sa settings page na may button na "Connect GitHub". Kung wala sa builder mo, puwede mong i-export ang code at ikaw ang mag-push, o humingi ng tulong sa developer para sa isang beses na setup.

Bago ang unang push, siguraduhing hindi kasama sa repository ang mga bagay na hindi dapat naroon:

Tingnan ang .gitignore file. Siguraduhing kasama roon ang .env files, node_modules, mga build output folder, at anumang file na may lamang secrets. Sabihin mo sa akin kung ano ang idinagdag mo.

Hakbang 2: Mag-commit pagkatapos ng bawat gumaganang pagbabago

Ang commit ay naka-save na snapshot na may mensahe. Ang gawing mahalaga: mag-commit kapag may gumagana na, bago ka humingi ng susunod.

1. Magprompt para sa isang pagbabago.
2. Tingnan ito sa preview.
3. Kung gumagana, mag-commit (o mag-sync) na may mensahe.
4. Saka ka lumipat sa susunod.

Ang maliliit na commit ay nangangahulugang kapag may nasira, alam mo kung aling pagbabago ang may kasalanan, at ang pag-undo nito ay hindi nagtatapon ng ibang trabaho.

Hakbang 3: Sumulat ng mensaheng mababasa mo pagkatapos

Ang mabuting mensahe ay nagsasabi kung ano ang nagbago at bakit, sa isang linya:

• Mabuti: Idagdag ang CSV export sa orders page
• Mabuti: Ayusin ang booking form na tumatanggi sa oras pagkatapos ng 6pm
• Hindi nakakatulong: update, changes, fix stuff

Puwede mo ring hilingin sa AI na isulat ang mga ito:

Ibuod ang mga pagbabago mula sa huling commit sa isang linya, magsimula sa pandiwa, at wala pang 70 karakter.

Hakbang 4: Gumamit ng branch para sa delikadong gawain

Ang branch ay hiwalay na linya ng trabaho. Puwede mong subukan ang isang bagay sa branch, at kung hindi ito umubra, puwede mo itong iwan nang hindi ginagalaw ang pangunahing bersyon.

Gumamit ng branch kapag:

• Malaki ang pagbabago (redesign, bagong payment flow, pagbabago sa database).
• May ibang taong gumagawa sa parehong app.
• Gusto mong may magrepaso ng pagbabago bago ito mapunta sa live.

Kapag tapos at nasubukan na ang trabaho, mine-merge ito pabalik sa pangunahing branch. Sa GitHub, kadalasang nangyayari ito sa pamamagitan ng pull request, isang pahinang nagpapakita ng mga pagbabago para sa pagrepaso. Kung isang branch lang ang sini-sync ng builder mo, ang developer ang puwedeng mag-manage ng mga branch sa panig ng GitHub.

Hakbang 5: Mag-undo nang ligtas

Kapag nasira ng prompt ang app, pigilan ang tuksong magprompt pa ng limang beses sa ibabaw nito. Bumalik sa huling gumaganang bersyon at subukan ang mas malinaw na prompt.

• Sa builder: gamitin ang checkpoint o restore feature nito, kung meron.
• Sa Git: ang git revert ay gumagawa ng bagong commit na nag-uundo sa lumang commit, kaya buo ang history. Ito ang ligtas na piliin kapag may ibang nag-pull na ng code.
• Iwasan ang git push --force sa shared branch maliban kung alam mo talaga kung bakit. Binubura nito ang history para sa lahat.

Kung hindi ka sigurado, itanong:

Sinira ng huling pagbabago ang login page. Ipakita mo kung aling mga file ang binago nito kumpara sa nakaraang commit, at ipaliwanag kung ano ang ginawa ng bawat pagbabago. Huwag munang may baguhin.

Hakbang 6: Mag-pull bago magprompt

Kung binago ng developer o ibang tool ang code sa GitHub, hindi ito malalaman ng AI builder hangga't hindi mo na-pull ang mga pagbabagong iyon. Ang pagprompt sa lumang code ay nagdudulot ng conflict at pagkawala ng trabaho.

• Mag-pull sa simula ng bawat session.
• Pagkasunduan kung sino ang nag-e-edit ng ano, at iwasang sabay na galawin ng dalawang panig ang parehong file.
• Kung magkaroon ka ng merge conflict (dalawang pagbabago sa parehong linya), hilingin sa developer o sa AI na ayusin ito at ipaliwanag ang pinili nila.

Halimbawang prompt

Bago tayo magsimula: ano ang nagbago sa repository mula sa huling session ko? Ibuod ang mga commit.

Gawin ang susunod na pagbabago nang mag-isa: magdagdag ng "Duplicate" button sa bawat invoice. Huwag nang may ibang babaguhin, para mai-commit ko ito nang hiwalay.

Tiyakin na walang API key, password, o .env file na naka-track sa Git, kasama na sa mga nakaraang commit. Pangalan ng file lang ang iulat, hindi ang mga halaga.

Mga karaniwang pagkakamali

• Pag-commit ng secrets. Kapag nasa Git history na ang isang key, nakalantad na ito, kahit burahin mo pa ang file. Palitan ito.
• Isang malaking commit kada linggo. Hindi mo maa-undo ang isang pagbabago nang hindi nauundo ang lahat ng kasama nito.
• Mga mensaheng "update". Nagiging walang silbi ang history sa paghahanap ng sira.
• Pagprompt sa lumang code. Mag-pull muna kapag may ibang nag-e-edit.
• Force-push para ayusin ang pagkakamali. Maaari nitong burahin ang trabaho ng ibang tao. Mag-revert na lang.
• Pag-commit ng node_modules. Napakalaki nito at muling nililikha naman mula sa lock file.

Checklist

• Nakakonekta ang project sa private repository.
• Ina-ignore ng .gitignore ang .env, node_modules, build output, at secrets.
• Nag-co-commit ako pagkatapos ng bawat gumaganang pagbabago.
• Sinasabi ng mga mensahe ng commit kung ano ang nagbago sa isang linya.
• Ang malaki o delikadong pagbabago ay nasa branch at nire-review.
• Nag-pull ako bago magprompt kapag may ibang nag-e-edit ng code.
• Nag-uundo ako gamit ang checkpoints o git revert, hindi force-push.
• Napalitan na ang anumang key na naka-commit kailanman.

Git sa Mythex

Nagse-save ang Mythex ng git checkpoint pagkatapos ng bawat matagumpay na turn ng agent, at ang Revert to this point ay ibinabalik ang project sa puntong iyon. Ito ang builder-side na undo na inilarawan sa hakbang 5. Tingnan ang Iterate without rebuilding.

Sa Pro, ikinokonekta ng GitHub sync ang isang repository mula sa project settings para ma-push at ma-pull mo ito, at ang export naman ay nagda-download ng project na walang kasamang secrets at node_modules. Tingnan ang GitHub, export, and import. Ang pagkonekta ng GitHub bago mo ibigay ang project sa developer ay nagpapadali ng paghahatid. Tingnan ang paano magtrabaho kasama ang developer sa app na ginawa ng AI at paano i-export at i-self-host ang app na ginawa ng AI.

Mga tanong