Ce este GitHub? Controlul versiunilor pentru cei care nu sunt dezvoltatori

GitHub este un site web care păstrează codul proiectelor software împreună cu istoricul lor complet, ca să poți vedea fiecare modificare, să anulezi greșelile și să lucrezi la același proiect împreună cu alte persoane. Se bazează pe Git, un software gratuit care înregistrează instantanee ale fișierelor unui proiect în timp. Git este instrumentul care păstrează istoricul; GitHub este locul online în care acel istoric este partajat, salvat în copie de siguranță și discutat.

Dacă construiești cu AI, GitHub înseamnă în primul rând două lucruri: să deții o copie a codului tău în afara instrumentului în care l-ai construit și să îl predai unui dezvoltator în formatul pe care îl folosește deja.

De ce contează când construiești cu AI

Un constructor de aplicații cu AI scrie și modifică rapid multe cod, iar nu fiecare modificare este o îmbunătățire. Controlul versiunilor este modalitatea prin care păstrezi totul în siguranță.

• Anulezi cu încredere. Fiecare modificare salvată este un instantaneu. Dacă AI-ul strică ceva, revii la ultima versiune bună.
• Proprietate. Codul din propriul tău cont GitHub rămâne al tău dacă schimbi instrumentele, dacă încetezi să plătești pentru unul dintre ele sau dacă vrei o a doua părere.
• Lucrul cu dezvoltatorii. Aproape orice dezvoltator folosește Git zilnic. Un depozit le permite să verifice ce a scris AI-ul, să îl corecteze și să trimită modificările înapoi.
• Publicarea în alt loc. Multe platforme de găzduire pot publica direct dintr-un depozit GitHub.

O analogie din viața de zi cu zi: modificările urmărite plus un drive partajat

Gândește-te la un document cu urmărirea modificărilor activată, salvat într-un drive partajat.

• Git este urmărirea modificărilor: fiecare editare este înregistrată, cu cine a făcut-o, când și de ce, iar tu poți reveni la orice versiune.
• GitHub este drive-ul partajat: documentul trăiește online, alții pot obține o copie și există un loc în care se pot adăuga comentarii și aprobări.
• O ramură (branch) este ca o copie salvată cu numele „schiță — secțiune nouă de prețuri”, ca să poți experimenta fără să atingi versiunea de care depinde toată lumea. Dacă experimentul funcționează, îl integrezi înapoi.

Diferența față de un document este scara. O aplicație înseamnă sute de fișiere, iar Git le urmărește pe toate împreună, deci un instantaneu reprezintă starea întregului proiect deodată.

Termeni Git și GitHub pe care îi vei întâlni

Două puncte merită subliniate. În primul rând, istoricul Git este permanent prin design: dacă o parolă este salvată (commit) și trimisă (push), ștergerea ei într-un commit ulterior nu o elimină din istoric. În al doilea rând, un commit este util doar prin mesajul său. „Corectează dublarea rezervărilor când doi oameni rezervă simultan” te ajută mai târziu; „actualizare” nu.

Un exemplu practic: predarea unei aplicații construite cu AI unui freelancer

Ai construit un portal pentru clienți cu un constructor de aplicații cu AI. Funcționează, dar vrei ca un dezvoltator freelancer să adauge o integrare dificilă cu software-ul tău de contabilitate.

1. Conectează proiectul la un depozit privat nou pe GitHub și fă push. Depozitul conține acum codul și istoricul său.
2. Verifică ce conține. Deschide depozitul pe GitHub. Nu ar trebui să existe niciun fișier .env și nicio cheie API în cod. Secretele rămân în setările platformei și sunt împărtășite freelancerului separat, dacă este cazul — vezi variabilele de mediu și secretele.
3. Invită freelancerul ca colaborator doar la acel depozit.
4. Lucrează pe o ramură numită ceva de genul accounting-sync, face commit-uri pe parcurs și deschide o cerere de integrare (pull request) când termină.
5. Revizuiești cererea de integrare. Chiar fără să citești cod, poți citi descrierea, verifica ce fișiere s-au schimbat și pune întrebări în comentarii.
6. Integrează când ești mulțumit, apoi fă pull cu modificările înapoi în constructorul tău, ca tu și AI-ul să continuați de la noua versiune.

Pe parcurs, poți vedea exact ce s-a schimbat și poți anula modificarea dacă este nevoie. Asta este toată valoarea controlului versiunilor, dintr-un singur flux de lucru. Dacă încă cântărești dacă să aduci un dezvoltator, vezi angajează un dezvoltator sau construiește cu AI.

Greșeli frecvente și concepții greșite

• „GitHub și Git sunt același lucru.” Git funcționează fără GitHub; alternative precum GitLab și Bitbucket găzduiesc și ele depozite Git.
• „GitHub îmi va rula aplicația.” GitHub stochează cod. Rularea acestuia pentru public este găzduire web, un serviciu separat (deși unele platforme pot publica din GitHub).
• Salvarea secretelor în commit-uri. Cea mai dăunătoare și cea mai frecventă greșeală. Folosește .gitignore pentru fișierele .env și înlocuiește orice cheie care a fost vreodată trimisă.
• O singură ramură și niciun mesaj. Este în regulă pentru experimente solo, dar dă commit-urilor mesaje clare și folosește ramuri pentru orice este riscant.
• Editarea în două locuri simultan. Dacă modifici codul în GitHub și în constructorul tău cu AI fără să faci pull între ele, creezi conflicte. Alege un singur loc de editare pe rând și sincronizează înainte să schimbi.
• Credința că un depozit privat este o copie de siguranță a tuturor. Conține cod, nu conținutul bazei de date sau fișierele încărcate. Acestea au nevoie de propriile copii de siguranță.

Ce să ceri constructorului tău cu AI

• „Adaugă un .gitignore care exclude .env, folderele cu dependențe și rezultatul build-ului.”
• „Scrie un README care explică cum se instalează, ce variabile de mediu sunt necesare (doar numele) și cum se rulează aplicația.”
• „Adaugă un .env.example cu fiecare nume de variabilă și fără valori reale.”
• „Folosește mesaje de commit clare și descriptive pentru fiecare modificare.”

Aceste patru cereri creează un depozit pe care un dezvoltator îl poate prelua în câteva minute. Pentru mutarea aplicației pe propriile servere, vezi cum să exporți și să self-hostezi o aplicație construită cu AI, iar pentru consolidarea ei înainte de utilizatorii reali, cum duci un prototip AI în producție.

GitHub și Mythex

Mythex păstrează istoricul pentru tine pe orice plan: după fiecare tură reușită a agentului salvează un checkpoint, care este un instantaneu Git la care poți reveni. Pe Pro, poți conecta GitHub și să faci push sau pull ale proiectului către propriul tău depozit sau poți descărca întregul proiect ca arhivă; secretele și dependențele instalate sunt excluse din exporturi. GitHub este aici pentru sincronizarea codului, nu pentru autentificarea în Mythex. Vezi GitHub, export și import în documentație și pagina de prețuri pentru ce include fiecare plan.

Întrebări