Kuidas kasutada Giti AI-ga ehitatud rakendusega
Giti kasutamiseks AI-ga ehitatud rakendusega ühenda projekt Giti hoidlaga, tee commit pärast iga töötavat muudatust, kirjuta igale muudatusele üherealine sõnum ja hoia saladused välja faili .gitignore abil. Riskantse töö jaoks kasuta haru, tõmba enne uut käsku muudatused, kui keegi teine koodi muutis, ja kui AI midagi katkestab, mine tagasi viimase töötava commit'i juurde, selle asemel et katkise koodi peale veel käske anda.
Git on versioonihaldus: ajalugu iga salvestatud koodiversioonist. GitHub on veebisait, mis hoiab Giti hoidlaid internetis. Kui need on sulle uued, alusta lehelt mis on GitHub. See juhend räägib harjumustest, mis muudavad Gitist kasulikku, kui suurema osa koodi kirjutab AI.
Miks Git on AI-ga tööd tehes olulisem
AI võib ühe vastusega muuta kakskümmend faili. See on kiire, aga tähendab ka seda, et üks käsk võib vaikselt katkestada asja, mis eile töötas. Git annab sulle:
- Tagasitee. Iga commit'itud versiooni saab taastada.
- Ülevaate muutustest. Näed täpselt, milliseid faile ja ridu käsk puudutas.
- Koopia väljaspool koostajat. Sinu kood asub kohas, mida sa kontrollid.
- Standardse üleandmise. Iga arendaja, hosting või tööriist saab Giti hoidlaga töötada.
Samm 1: ühenda hoidla
Loo hoidla (tavaliselt privaatne) GitHubis või sarnases teenuses ja ühenda oma projekt sellega. Enamik Giti toetavaid AI-rakenduste koostajaid teeb seda seadete lehel nupuga „Connect GitHub“. Kui sinu koostajal seda ei ole, saad koodi eksportida ja ise üles lükata või paluda arendajal seadistus kord ära teha.
Enne esimest üleslükkamist veendu, et hoidla ignoreerib asju, mis sinna ei kuulu:
Vaata üle .gitignore-fail. Veendu, et see välistab .env-failid, node_modules, ehitustulemuste kaustad ja kõik failid, mis sisaldavad saladusi. Ütle, mida lisasid.
Samm 2: tee commit pärast iga töötavat muudatust
Commit on salvestatud hetktõmmis koos sõnumiga. Oluline harjumus on: tee commit siis, kui midagi töötab, enne kui küsid järgmist.
- Küsi üks muudatus.
- Kontrolli seda eelvaates.
- Kui see töötab, tee commit (või sünkrooni) sõnumiga.
- Seejärel liigu edasi.
Väikesed commit'id tähendavad, et kui midagi katkeb, tead, milline muudatus selle tekitas, ja selle tagasi võtmine ei kustuta muud tööd.
Samm 3: kirjuta sõnumid, mida saad hiljem lugeda
Hea sõnum ütleb ühel real, mis muutus ja miks:
- Hea:
Lisa tellimuste lehele CSV-eksport - Hea:
Paranda broneerimisvorm, mis lükkas tagasi kellaajad pärast kella 18 - Ei too kasu:
uuendus,muudatused,parandasin asju
Sõnumi võid lasta kirjutada AI-l:
Võta kokku muudatused viimase commit'i järel ühe reaga, alustades tegusõnaga, kuni 70 tähemärki.
Samm 4: kasuta riskantse töö jaoks harusid
Haru on eraldi töölõik. Võid midagi proovida harus ja kui see ei õnnestu, loobuda sellest, jättes peamise versiooni puutumata.
Kasuta haru, kui:
- muudatus on suur (uuendatud disain, uus makseviis, andmebaasi muudatus);
- teine inimene töötab samas rakenduses;
- tahad, et keegi vaataks muudatuse üle enne, kui see läheb avalikuks.
Kui töö on tehtud ja testitud, ühendatakse see tagasi peaharusse, ehk merge'itakse. GitHubis toimub see tavaliselt pull request'i kaudu, mis on lehekülg muudatuste ülevaatamiseks. Kui sinu koostaja sünkroonib ainult ühte harugu, saab haldust teha arendaja GitHubi poolel.
Samm 5: võta muudatus turvaliselt tagasi
Kui käsk rikub rakenduse, ära kiusatle andma veel viit käsku peale. Mine tagasi viimase head versiooni juurde ja proovi selgemat käsku.
- Koostajas: kasuta kontrollpunkti või taastamise funktsiooni, kui see on olemas.
- Gitis:
git revertloob uue commit'i, mis võtab vana muudatuse tagasi ja jätab ajaloo puutumata. See on turvaline valik koodi puhul, mida teised on juba alla tõmmanud. - Väldi
git push --force'i jagatud harul, kui sa täpselt ei tea, miks. See kirjutab ajaloo kõigi jaoks ümber.
Kui pole kindel, küsi:
Viimane muudatus katkestas sisselogimislehe. Näita, mis failid muutusid võrreldes eelmise commit'iga, ja selgita, mida iga muudatus tegi. Ära veel midagi muuda.
Samm 6: tõmba muudatused enne käskimist
Kui arendaja või mõni muu tööriist muudab koodi GitHubis, ei tea AI-koostaja sellest enne, kui sa need sisse tõmbad (pull). Vana koodi peale käsu andmine tekitab konflikte ja kaotatud tööd.
- Tõmba muudatused iga töösessiooni alguses.
- Lepi kokku, kes mida muudab, ja väldi seda, et mõlemad pooled muudaksid samu faile samal ajal.
- Kui tekib merge-konflikt (kaks muudatust samadel ridadel), palu arendajal või AI-l konflikt lahendada ja selgitada tehtud valikut.
Näidisküsimused
Enne alustamist: mis on repos muutunud pärast mu viimast sessiooni? Võta commit'id kokku.
Tee järgmine muudatus eraldi: lisa iga arve juurde nupp „Dubleeri“. Ära muuda midagi muud, et saaksin selle eraldi commit'ida.
Kontrolli, et Giti ei ole jälgitud ühtegi API-võtit, parooli ega .env-faili, sealhulgas varasemates commit'ides. Too välja ainult failinimed, mitte väärtused.
Levinud vead
- Saladuste commit'imine. Kui võti on Giti ajaloos, on see avalik, isegi kui fail hiljem kustutatakse. Vaheta võti välja.
- Üks suur commit nädalas. Ühte muudatust ei saa tagasi võtta ilma kõigita.
- Sõnumid nagu „uuendus“. Ajalugu muutub kasutuks, kui otsid, mis katkestas.
- Käskimine vanal koodil. Kui keegi teine muudab, tõmba enne muudatused.
- Vea parandamine force-push'iga. See võib kustutada teiste töö. Kasuta selle asemel revert'i.
node_modules'i commit'imine. See on suur ja luuakse lukufaili järgi niikuinii uuesti.
Kontrollnimekiri
- Projekt on ühendatud privaatse hoidlaga.
-
.gitignorevälistab.env,node_modules, ehitustulemused ja saladused. - Teen commit'i pärast iga töötavat muudatust.
- Commit'i sõnumid ütlevad ühel real, mis muutus.
- Suured või riskantsed muudatused lähevad harusse ja neid vaadatakse üle.
- Tõmban muudatused enne käskimist, kui keegi teine koodi muudab.
- Võtan muudatusi tagasi kontrollpunktidega või
git revert'iga, mitte force-push'iga. - Iga võti, mis on kunagi commit'itud, on välja vahetatud.
Git Mythexis
Mythex salvestab pärast iga õnnestunud agendi käiku Giti kontrollpunkti ning funktsioon Revert to this point viib projekti selle punkti juurde. See on koostaja poolne tagasivõtmine, mida kirjeldatakse 5. sammus. Vaata Iterate without rebuilding.
Pro-paketis ühendab GitHub sync projektiseadetest hoidla, nii et saad sinna üles ja alla lükata, ning export laeb projekti alla ilma saladuste ja node_modules'ita. Vaata GitHub, export ja import. Kui ühendad GitHubi enne projekti arendajale üleandmist, on see palju lihtsam. Vaata kuidas töötada arendajaga AI-ga ehitatud rakenduse kallal ja kuidas eksportida ning ise majutada AI-ga ehitatud rakendust.
Küsimused
Kas mul on Giti vaja, kui mu AI-rakenduse koostajal on kontrollpunktid?
Kontrollpunktid katavad tagasivõtmise ehitamise ajal. Git lisab koodi koopia väljaspool koostajat, ajaloo, mida teised saavad lugeda, ja standardse viisi, kuidas arendaja või mõni muu tööriist samal koodil töötab. Kui rakendusel on tähtsust, kasuta mõlemat.
Kui tihti peaksin AI-ga ehitades commit'ima?
Pärast iga töötavat muudatust, tavaliselt pärast iga õnnestunud käsku või väikest käskude rühma. Väikesed commit'id teevad lihtsaks leida ja tagasi võtta selle ühe muudatuse, mis midagi katkestas.
Mida ei tohi Giti kunagi commit'ida?
API-võtmeid, paroole, .env-faile päris väärtustega ja paigaldatud sõltuvuste kaustu, näiteks node_modules. Lisa need enne esimest commit'i faili .gitignore ning vaheta välja iga võti, mis on kunagi commit'itud.
Kas ma saan koodi GitHubis muuta ja AI-ga edasi ehitada?
Jah, kui sinu koostaja suudab GitHubist muudatusi tõmmata. Tõmba enne uut käsku muudatused, et AI töötaks värskeimal koodil, ja väldi olukorda, kus mõlemad pooled muudavad samal ajal samu faile.