Cum folosești Git cu o aplicație construită cu AI

Pentru a folosi Git cu o aplicație construită cu AI, conectează proiectul la un depozit Git, fă commit după fiecare modificare care funcționează, scrie un mesaj dintr-un rând care spune ce s-a schimbat și ține secretele afară cu un .gitignore. Folosește o ramură pentru orice e riscant, fă pull înainte de următorul prompt dacă altcineva a schimbat codul și, când AI-ul strică ceva, întoarce-te la ultimul commit bun în loc să dai prompturi peste dezordine.

Git este controlul versiunilor: un istoric al fiecărei versiuni salvate a codului tău. GitHub este un site care găzduiește online depozite Git. Dacă ți se par noi, începe cu ce este GitHub. Acest ghid se ocupă de obiceiurile care fac Git util atunci când un AI scrie cea mai mare parte din cod.

De ce contează mai mult Git cu AI

Un AI poate modifica douăzeci de fișiere într-o singură tură. Asta e rapid, dar înseamnă și că un prompt poate strica discret ceva ce ai testat ieri. Git îți oferă:

• O cale de întoarcere. Orice versiune salvată poate fi restaurată.
• O evidență a modificărilor. Poți vedea exact ce fișiere și ce linii a atins un prompt.
• O copie în afara builder-ului. Codul tău stă într-un loc pe care îl controlezi.
• Un transfer standard. Orice dezvoltator, găzduire sau instrument poate lucra dintr-un depozit Git.

Pasul 1: Conectează un depozit

Creează un depozit (de obicei privat) pe GitHub sau pe un serviciu similar și conectează proiectul la el. Majoritatea constructorilor de aplicații cu AI care suportă Git fac asta dintr-o pagină de setări, cu un buton „Connect GitHub”. Dacă al tău nu are, poți exporta codul și să-l împingi singur, sau poți cere unui dezvoltator să facă configurarea o dată.

Înainte de primul push, asigură-te că depozitul ignoră lucrurile care nu ar trebui să fie în el:

Verifică fișierul .gitignore. Asigură-te că exclude fișierele .env, node_modules, folderele cu fișierele generate și orice fișier care conține secrete. Spune-mi ce ai adăugat.

Pasul 2: Fă commit după fiecare modificare care funcționează

Un commit este o copie salvată, cu un mesaj. Obiceiul care contează: fă commit când ceva funcționează, înainte să ceri următorul lucru.

1. Cere o singură modificare printr-un prompt.
2. Verific-o în previzualizare.
3. Dacă funcționează, fă commit (sau sincronizează) cu un mesaj.
4. Apoi treci mai departe.

Commit-urile mici înseamnă că, atunci când ceva se strică, știi ce modificare a cauzat problema, iar anularea ei nu aruncă și celelalte lucrări.

Pasul 3: Scrie mesaje pe care le poți citi mai târziu

Un mesaj bun spune ce s-a schimbat și de ce, într-un rând:

• Bun: Adaugă export CSV în pagina comenzilor
• Bun: Repară formularul de rezervare care respinge orele după 18:00
• Inutil: update, changes, fix stuff

Poți cere AI-ului să le scrie:

Rezumă modificările de după ultimul commit într-un singur rând, care începe cu un verb și are sub 70 de caractere.

Pasul 4: Folosește ramuri pentru lucrul riscant

O ramură este o linie separată de lucru. Poți încerca ceva pe o ramură și, dacă nu iese, o abandonezi fără să atingi versiunea principală.

Folosește o ramură când:

• Modificarea este mare (o regândire a designului, un flux nou de plată, o schimbare a bazei de date).
• Altcineva lucrează la aceeași aplicație.
• Vrei ca cineva să verifice modificarea înainte să ajungă live.

Când lucrul este gata și testat, este îmbinat (merged) înapoi în ramura principală. Pe GitHub, asta se face de obicei printr-un pull request, o pagină care arată modificările pentru revizuire. Dacă builder-ul tău sincronizează doar o ramură, un dezvoltator poate gestiona ramurile din partea GitHub.

Pasul 5: Anulează în siguranță

Când un prompt strică aplicația, rezistă tentației de a da încă cinci prompturi peste el. Întoarce-te la ultima versiune bună și încearcă un prompt mai clar.

• În builder: folosește funcția de checkpoint sau restaurare, dacă există.
• În Git: git revert creează un commit nou care anulează unul vechi și păstrează istoricul intact. Este alegerea sigură pentru codul pe care alții l-ar fi putut deja trage.
• Evită git push --force pe o ramură partajată, decât dacă știi exact de ce. Rescrie istoricul pentru toată lumea.

Dacă nu ești sigur, întreabă:

Ultima modificare a stricat pagina de autentificare. Arată-mi ce fișiere a schimbat față de commit-ul anterior și explică ce a făcut fiecare modificare. Nu schimba nimic încă.

Pasul 6: Fă pull înainte să dai prompturi

Dacă un dezvoltator sau alt instrument schimbă codul pe GitHub, builder-ul AI nu știe până nu aduci modificările cu pull. Dacă dai prompturi pe cod vechi, apar conflicte și pierzi lucru.

• Fă pull la începutul fiecărei sesiuni.
• Stabilește cine editează ce și evitați ca ambele părți să modifice aceleași fișiere în același timp.
• Dacă apare un conflict de îmbinare (două modificări pe aceleași linii), cere dezvoltatorului sau AI-ului să-l rezolve și să explice alegerea făcută.

Exemple de prompturi

Înainte să începem: ce s-a schimbat în depozit de la ultima mea sesiune? Rezumă commit-urile.

Fă următoarea modificare de una singură: adaugă un buton „Duplică” la fiecare factură. Nu schimba nimic altceva, ca să pot face commit separat.

Verifică dacă nu există chei API, parole sau fișiere .env urmărite în Git, inclusiv în commit-urile vechi. Raportează doar numele fișierelor, nu valorile.

Greșeli frecvente

• Commit cu secrete. Odată ajunsă în istoricul Git, o cheie este expusă, chiar dacă ștergi fișierul mai târziu. Rotește-o.
• Un commit gigant pe săptămână. Nu poți anula o singură modificare fără să le anulezi pe toate.
• Mesaje de tipul „update”. Istoricul devine inutil când vrei să găsești ce a stricat ceva.
• Prompturi pe cod vechi. Fă pull primul când altcineva editează.
• Force-push ca să repari o greșeală. Poate șterge munca altor persoane. Folosește revert.
• Commit cu node_modules. Este uriaș și oricum se recreează din fișierul de lock.

Listă de verificare

• Proiectul este conectat la un depozit privat.
• .gitignore exclude .env, node_modules, fișierele generate și secretele.
• Fac commit după fiecare modificare care funcționează.
• Mesajele de commit spun ce s-a schimbat, într-un rând.
• Modificările mari sau riscante merg pe o ramură și sunt revizuite.
• Fac pull înainte de prompt când altcineva editează codul.
• Anulez cu checkpoint-uri sau cu git revert, nu cu force-push.
• Orice cheie care a fost vreodată commisă a fost rotită.

Git pe Mythex

Mythex salvează un checkpoint Git după fiecare tură reușită a agentului, iar Revino la acest punct readuce proiectul la el — anularea din builder descrisă la pasul 5. Vezi Iterează fără să reconstruiești.

Pe Pro, sincronizarea cu GitHub conectează un depozit din setările proiectului, ca să poți trimite și trage modificări, iar exportul descarcă proiectul fără secrete și fără node_modules. Vezi GitHub, export și import. Conectarea GitHub înainte de a preda un proiect unui dezvoltator face predarea mult mai simplă — vezi cum lucrezi cu un dezvoltator la o aplicație făcută cu AI și cum exporți și găzduiești singur o aplicație făcută cu AI.

Întrebări