Jak používat Git s aplikací vytvořenou pomocí AI
Abyste mohli s aplikací vytvořenou pomocí AI používat Git, připojte projekt k Git repozitáři, commitujte po každé funkční změně, napište jednořádkovou zprávu o tom, co se změnilo, a tajné údaje držte mimo repozitář pomocí .gitignore. Pro rizikovou práci použijte větev, pokud někdo jiný změnil kód, stáhněte změny (pull) dřív, než znovu použijete prompt, a když AI něco rozbije, vraťte se k poslednímu funkčnímu commitu místo toho, abyste psali další prompt na vrchol nepořádku.
Git je správa verzí: historie každé uložené verze vašeho kódu. GitHub je web, který ukládá Git repozitáře online. Pokud jsou to pro vás nové pojmy, začněte článkem co je GitHub. Tento průvodce se zabývá návyky, které dělají Git užitečným, když většinu kódu píše AI.
Proč je Git důležitější s AI
AI dokáže za jedno kolo změnit dvacet souborů. To je rychlé, zároveň to znamená, že jeden prompt může nenápadně rozbít něco, co jste včera otestovali. Git vám dává:
- Cestu zpět. Kteroukoli commitnutou verzi lze obnovit.
- Záznam o změnách. Vidíte přesně, které soubory a řádky prompt dotkl.
- Kopii mimo nástroj. Váš kód je uložený tam, kde ho máte pod kontrolou.
- Standardní předání. Jakýkoli vývojář, hosting nebo nástroj může pracovat z Git repozitáře.
Krok 1: Připojte repozitář
Vytvořte repozitář (obvykle soukromý) na GitHubu nebo podobné službě a připojte k němu svůj projekt. Většina nástrojů na tvorbu aplikací, které Git podporují, to dělá přes stránku nastavení s tlačítkem „Connect GitHub“. Pokud vaše nástroj nic takového nemá, můžete kód exportovat a nahrát jej sami, nebo požádat vývojáře, aby to jednou nastavil.
Před prvním nahráním se ujistěte, že repozitář ignoruje věci, které v něm být nemají:
Zkontroluj soubor .gitignore. Ujisti se, že vylučuje soubory .env, node_modules, složky s výstupem sestavení a jakýkoli soubor obsahující tajné údaje. Řekni mi, co jsi přidal.
Krok 2: Commitujte po každé funkční změně
Commit je uložený snímek se zprávou. Návyk, na kterém záleží: commitujte, když něco funguje, dřív než požádáte o další věc.
- Zadejte prompt na jednu změnu.
- Ověřte ji v náhledu.
- Pokud funguje, commitujte (nebo synchronizujte) se zprávou.
- Pak pokračujte dál.
Malé commity znamenají, že když se něco rozbije, víte, která změna to způsobila, a její vrácení nesmaže ostatní práci.
Krok 3: Pište zprávy, které si přečtete později
Dobrá zpráva říká, co se změnilo a proč, v jednom řádku:
- Dobře:
Přidat export CSV na stránku objednávek - Dobře:
Opravit odmítání časů po 18:00 v rezervačním formuláři - Nepoužitelné:
update,změny,oprava všeho
Zprávy můžete nechat napsat AI:
Shrň změny od posledního commitu jedním řádkem, začni slovesem a drž se pod 70 znaky.
Krok 4: Pro rizikovou práci používejte větve
Větev je samostatná linie práce. Můžete na větvi něco zkusit a když to nevyjde, zahodit ji, aniž byste se dotkli hlavní verze.
Větev použijte, když:
- je změna rozsáhlá (redesign, nový platební tok, změna databáze),
- na stejné aplikaci pracuje někdo další,
- chcete, aby změnu před nasazením někdo zkontroloval.
Až je práce hotová a otestovaná, sloučí se zpět do hlavní větve. Na GitHubu se to obvykle děje přes pull request, stránku, která ukazuje změny k revizi. Pokud váš nástroj synchronizuje jen jednu větev, může větve spravovat vývojář na straně GitHubu.
Krok 5: Vracejte se bezpečně
Když prompt aplikaci rozbije, odolejte nutkání zadat dalších pět promptů navrch. Vraťte se k poslední funkční verzi a zkuste jasnější prompt.
- V nástroji: použijte jeho funkci checkpointu nebo obnovení, pokud ji má.
- V Gitu:
git revertvytvoří nový commit, který starý vrátí zpět, a historie zůstane zachována. Je to bezpečná volba pro kód, který si mohli stáhnout ostatní. - Vyhněte se
git push --forcena sdílené větvi, pokud přesně nevíte proč. Přepíše historii pro všechny.
Pokud si nejste jisti, zeptejte se:
Poslední změna rozbila přihlašovací stránku. Ukaž mi, které soubory změnila oproti předchozímu commitu, a vysvětli, co každá změna dělala. Zatím nic neměň.
Krok 6: Stáhněte změny, než zadáte prompt
Pokud vývojář nebo jiný nástroj změní kód na GitHubu, nástroj na tvorbu AI to nepozná, dokud tyto změny nestáhnete (pull). Prompt na starém kódu vede ke konfliktům a ztracené práci.
- Stahujte změny na začátku každé session.
- Domluvte se, kdo co upravuje, a vyhněte se tomu, aby obě strany upravovaly stejné soubory najednou.
- Pokud dostanete konflikt při sloučení (dvě změny na stejných řádcích), požádejte vývojáře nebo AI, aby ho vyřešili a vysvětlili volbu.
Příklady promptů
Než začneme: co se od mé poslední session změnilo v repozitáři? Shrň commity.
Udělej příští změnu samostatně: přidej tlačítko „Duplikovat“ ke každé faktuře. Nic jiného neměň, ať ji mohu commitnout zvlášť.
Zkontroluj, že v Gitu nejsou sledovány žádné API klíče, hesla ani soubory .env, včetně minulých commitů. Uveď jen názvy souborů, ne hodnoty.
Časté chyby
- Commitování tajných údajů. Jakmile je klíč v historii Gitu, je vystavený, i když soubor později smažete. Změňte ho.
- Jeden obří commit za týden. Nemůžete vrátit jednu změnu, aniž byste vrátili všechny.
- Zprávy typu „update“. Historie se stane k hledání chyby nepoužitelnou.
- Prompt na zastaralém kódu. Když někdo jiný upravuje kód, nejdřív stáhněte změny.
- Force push jako oprava chyby. Může smazat práci ostatních. Použijte revert.
- Commitování
node_modules. Je obrovská a stejně se znovu vytvoří ze zamykacího souboru.
Kontrolní seznam
- Projekt je připojen k soukromému repozitáři.
-
.gitignorevylučuje.env,node_modules, výstup sestavení a tajné údaje. - Commituji po každé funkční změně.
- Zprávy commitů říkají jednou větou, co se změnilo.
- Velké nebo rizikové změny jdou na větev a procházejí revizí.
- Stahuji změny, než zadám prompt, pokud kód upravuje i někdo jiný.
- Vracím změny pomocí checkpointů nebo
git revert, ne force push. - Každý klíč, který se kdy dostal do commitu, byl změněn.
Git v Mythexu
Mythex uloží git checkpoint po každém úspěšném kole agenta a Revert to this point vrátí projekt k němu. Je to vrácení na straně nástroje, popsané v kroku 5. Viz Iterace bez přestavby.
V tarifu Pro synchronizace s GitHubem připojí repozitář z nastavení projektu, takže můžete odesílat a stahovat změny, a export stáhne projekt bez tajných údajů a bez node_modules. Viz GitHub, export a import. Připojení GitHubu před předáním projektu vývojáři předání výrazně zjednoduší — viz jak pracovat s vývojářem na aplikaci vytvořené pomocí AI a jak exportovat a provozovat vlastní hosting aplikace vytvořené pomocí AI.
Otázky
Potřebuji Git, když můj nástroj na tvorbu aplikací má checkpointy?
Checkpointy slouží k vrácení změn během vývoje. Git přidá kopii kódu mimo nástroj, historii, kterou mohou číst i jiní, a standardní způsob, jak na stejném kódu může pracovat vývojář nebo jiný nástroj. Pokud na aplikaci záleží, používejte obojí.
Jak často mám při tvorbě s AI commitovat?
Po každé změně, která funguje, obvykle po každém úspěšném promptu nebo malé skupině promptů. Malé commity usnadňují najít a vrátit jedinou změnu, která něco rozbila.
Co nikdy nesmí být v Gitu?
API klíče, hesla, soubory .env se skutečnými hodnotami a složky s nainstalovanými závislostmi, například node_modules. Přidejte je do .gitignore dřív, než uděláte první commit, a každý klíč, který se kdy dostal do commitu, změňte.
Mohu upravovat kód na GitHubu a dál pokračovat s AI?
Ano, pokud váš nástroj umí stahovat změny z GitHubu. Před dalším promptem stáhněte změny (pull), aby AI pracovala s nejnovějším kódem, a vyhněte se tomu, aby obě strany upravovaly stejné soubory ve stejnou dobu.