Kako uporabljati Git z aplikacijo, ustvarjeno z AI

Za uporabo Gita z aplikacijo, ustvarjeno z AI, povežite projekt z repozitorijem Git, shranjujte po vsaki delujoči spremembi, vsakič napišite enovrstično sporočilo, kaj se je spremenilo, in skrivnosti držite zunaj s pomočjo .gitignore. Za vsako tvegano delo uporabite vejo, če nekdo drug spremeni kodo, pred novim pozivom povlecite spremembe, in ko AI nekaj pokvari, se vrnite na zadnjo dobro shrambo, namesto da bi na to nalagali nove pozive.

Git je nadzor različic: zgodovina vsake shranjene različice vaše kode. GitHub je spletna stran, ki hrani repozitorije Git na spletu. Če so vam ti pojmi novi, začnite z kaj je GitHub. Ta vodnik govori o navadah, zaradi katerih je Git uporaben, ko večino kode piše AI.

Zakaj je Git pomembnejši pri AI

AI lahko v enem koraku spremeni dvajset datotek. To je hitro, a hkrati pomeni, da lahko en poziv tiho pokvari nekaj, kar ste včeraj preizkusili. Git vam daje:

• Pot nazaj. Katerokoli shranjeno različico lahko obnovite.
• Zapis sprememb. Natančno vidite, katere datoteke in vrstice je poziv spremenil.
• Kopijo zunaj graditelja. Vaša koda je tam, kjer jo lahko nadzirate.
• Standardno predajo. Vsak razvijalec, gostitelj ali orodje lahko dela iz repozitorija Git.

1. korak: povežite repozitorij

Ustvarite repozitorij (ponavadi zasebnega) na GitHubu ali podobni storitvi in povežite projekt z njim. Večina graditeljev aplikacij z AI, ki podpirajo Git, to naredi prek nastavitev z gumbom »Connect GitHub«. Če vaš tega nima, lahko kodo izvozite in jo sami potisnete (push) ali enkrat prosite razvijalca, da to nastavi.

Pred prvim potiskom poskrbite, da repozitorij ignorira stvari, ki v njem ne smejo biti:

Preveri datoteko .gitignore. Poskrbi, da izključuje datoteke .env, node_modules, mape z izhodnimi datotekami gradnje in vse datoteke, ki vsebujejo skrivnosti. Povej mi, kaj si dodal.

2. korak: shranjujte po vsaki delujoči spremembi

Shramba (commit) je shranjen posnetek s sporočilom. Navada, ki šteje: shranite, ko nekaj deluje, preden zahtevate naslednjo stvar.

1. Pozovite AI k eni spremembi.
2. Preverite v predogledu.
3. Če deluje, shranite (ali sinhronizirajte) s sporočilom.
4. Nato nadaljujte.

Majhne shrambe pomenijo, da ko se nekaj pokvari, veste, katera sprememba je to povzročila, in razveljavitev ne zavrže drugega dela.

3. korak: pišite sporočila, ki jih boste razumeli kasneje

Dobro sporočilo v eni vrstici pove, kaj se je spremenilo in zakaj:

• Dobro: Dodaj izvoz CSV na stran naročil
• Dobro: Popravi obrazec za rezervacije, ki zavrne čase po 18. uri
• Neuporabno: posodobitev, spremembe, popravki

AI lahko sporočila napiše tudi sam:

Povzemi spremembe od zadnje shrambe v enem stavku, ki se začne z glagolom, krajši od 70 znakov.

4. korak: za tvegana dela uporabite veje

Veja je ločena linija dela. Nekaj lahko preizkusite na veji in, če ne uspe, jo opustite, ne da bi se dotaknili glavne različice.

Vejo uporabite, kadar:

• je sprememba obsežna (prenova, nov tok plačil, sprememba baze).
• na isti aplikaciji dela še kdo drug.
• želite, da kdo spremembo pregleda, preden gre v živo.

Ko je delo končano in preizkušeno, se združi (merge) nazaj v glavno vejo. Na GitHubu to ponavadi poteka prek pull requesta, strani, ki prikazuje spremembe za pregled. Če vaš graditelj sinhronizira samo eno vejo, lahko veje na strani GitHuba upravlja razvijalec.

5. korak: varno razveljavite

Ko poziv aplikacijo pokvari, se ne izplača pozivati še petkrat zapored. Vrnite se na zadnjo dobro različico in poskusite z jasnejšim pozivom.

• V graditelju: uporabite kontrolno točko ali funkcijo obnovitve, če jo ima.
• V Gitu: git revert ustvari novo shrambo, ki razveljavi staro, in pri tem ohrani zgodovino. To je varna izbira za kodo, ki so jo drugi že povlekli.
• Izogibajte se git push --force na skupni veji, razen če natančno veste, zakaj. Tako se zgodovina prepiše za vse.

Če niste prepričani, vprašajte:

Zadnja sprememba je pokvarila stran za prijavo. Pokaži mi, katere datoteke je spremenila v primerjavi s prejšnjo shrambo, in razloži, kaj je naredila vsaka sprememba. Zaenkrat ne spreminjaj ničesar.

6. korak: pred pozivom povlecite spremembe

Če razvijalec ali drugo orodje spremeni kodo na GitHubu, graditelj z AI tega ne ve, dokler spremb ne povlečete (pull). Pozivanje na stari kodi povzroča konflikte in izgubo dela.

• Ob vsaki seji začnite s povlekom sprememb.
• Dogovorite se, kdo ureja kaj, in se izogibajte temu, da bi obe strani hkrati urejali iste datoteke.
• Če dobite konflikt pri združevanju (dve spremembi istih vrstic), prosite razvijalca ali AI, naj ga razrešita in pojasnita izbiro.

Primeri pozivov

Pred začetkom: kaj se je v repozitoriju spremenilo od moje zadnje seje? Povzemi shrambe.

Naredi naslednjo spremembo samostojno: dodaj gumb »Podvoji« k vsakemu računu. Ne spreminjaj ničesar drugega, da jo lahko shranim ločeno.

Preveri, da v Gitu ni sledenih nobenih ključev API, gesel ali datotek .env, tudi v prejšnjih shrambah. Poroči samo imena datotek, ne vrednosti.

Pogoste napake

• Shranjevanje skrivnosti. Ko je ključ v zgodovini Gita, je izpostavljen, tudi potem ko datoteko izbrišete. Zamenjajte ga.
• Ena velika shramba na teden. Ene spremembe ne morete razveljaviti, ne da bi razveljavili vse ostale.
• Sporočila kot »posodobitev«. Zgodovina postane neuporabna za iskanje, kaj je pokvarilo.
• Pozivanje na zastarelo kodo. Pred delom povlecite spremembe, če nekdo drug ureja.
• Prisilni potisk za popravek napake. Lahko izbriše delo drugih. Raje uporabite revert.
• Shranjevanje node_modules. Je ogromna mapa in se tako ali tako ponovno ustvari iz datoteke z zaklenjenimi različicami.

Kontrolni seznam

• Projekt je povezan z zasebnim repozitorijem.
• .gitignore izključuje .env, node_modules, izhodne datoteke gradnje in skrivnosti.
• Shranjujem po vsaki delujoči spremembi.
• Sporočila shramb v eni vrstici povedo, kaj se je spremenilo.
• Obsežne ali tvegane spremembe gredo na vejo in se pregledajo.
• Pred pozivom povlečem spremembe, kadar kdo drug ureja kodo.
• Razveljavim s kontrolnimi točkami ali git revert, ne s prisilnim potiskom.
• Vsak ključ, ki je bil kdajkoli shranjen, je zamenjan.

Git na Mythexu

Mythex po vsaki uspešni potezi agenta shrani kontrolno točko Gita, gumb Vrni na to točko pa projekt povrne na to stanje – to je razveljavitev na strani graditelja, opisana v 5. koraku. Glejte Iteriranje brez ponovne gradnje.

V paketu Pro sinhronizacija z GitHubom poveže repozitorij iz nastavitev projekta, da lahko potiskate in povlečete spremembe, izvoz pa prenese projekt brez skrivnosti in mape node_modules. Glejte GitHub, izvoz in uvoz. Če GitHub povežete, preden projekt predate razvijalcu, je predaja veliko lažja – glejte kako delati z razvijalcem na aplikaciji, ustvarjeni z AI in kako izvoziti in samostojno gostiti aplikacijo, ustvarjeno z AI.

Vprašanja