Com fer servir Git amb una app creada amb IA

Per fer servir Git amb una app creada amb IA, connecta el projecte a un repositori de Git, fes un commit després de cada canvi que funcioni, escriu un missatge d’una línia que digui què ha canviat i mantén els secrets fora amb un .gitignore. Fes servir una branca per a qualsevol cosa arriscada, fes pull abans de tornar a demanar canvis si algú més ha modificat el codi i, quan la IA trenqui alguna cosa, torna a l’últim commit correcte en lloc de fer més peticions sobre el desgavell.

Git és control de versions: un historial de totes les versions desades del codi. GitHub és un lloc web que emmagatzema repositoris de Git en línia. Si això és nou per a tu, comença amb què és GitHub. Aquesta guia tracta els hàbits que fan útil Git quan una IA escriu la major part del codi.

Per què Git importa més amb la IA

Una IA pot canviar vint fitxers en un sol torn. És ràpid, però també vol dir que una petició pot trencar en silenci alguna cosa que ahir havies comprovat. Git et dona:

• Una manera de tornar enrere. Qualsevol versió amb commit es pot restaurar.
• Un registre del que ha canviat. Pots veure exactament quins fitxers i quines línies ha tocat una petició.
• Una còpia fora del constructor. El teu codi viu en un lloc que controles.
• Un traspàs estàndard. Qualsevol desenvolupador, servei o eina pot treballar a partir d’un repositori de Git.

Pas 1: connecta un repositori

Crea un repositori (normalment privat) a GitHub o en un servei similar i connecta-hi el projecte. La majoria de constructors d’apps amb IA que admeten Git ho fan des d’una pàgina de configuració amb un botó «Connect GitHub». Si el teu no ho té, pots exportar el codi i pujar-lo tu mateix, o demanar a un desenvolupador que ho configuri una vegada.

Abans del primer push, assegura’t que el repositori ignora les coses que no hi han d’anar:

Revisa el fitxer .gitignore. Assegura’t que exclou els fitxers .env, node_modules, les carpetes de sortida de la compilació i qualsevol fitxer que contingui secrets. Digue’m què has afegit.

Pas 2: fes un commit després de cada canvi que funcioni

Un commit és una instantània desada amb un missatge. L’hàbit que importa: fes commit quan alguna cosa funcioni, abans de demanar la següent.

1. Demana un sol canvi.
2. Comprova’l a la vista prèvia.
3. Si funciona, fes commit (o sincronitza) amb un missatge.
4. Després, continua.

Amb commits petits, quan alguna cosa es trenca saps quin canvi l’ha causat, i desfer-lo no esborra altra feina.

Pas 3: escriu missatges que puguis llegir més tard

Un bon missatge diu què ha canviat i per què, en una línia:

• Bo: Afegeix l’exportació a CSV a la pàgina de comandes
• Bo: Corregeix el formulari de reserves que rebutjava hores després de les 18:00
• Poc útil: update, canvis, arregla coses

Pots demanar a la IA que els escrigui:

Resumeix els canvis des de l’últim commit en una línia, començant amb un verb, amb menys de 70 caràcters.

Pas 4: fes servir branques per al treball arriscat

Una branca és una línia de treball independent. Pots provar alguna cosa en una branca i, si no funciona, abandonar-la sense tocar la versió principal.

Fes servir una branca quan:

• El canvi és gran (un redisseny, un flux de pagament nou, un canvi a la base de dades).
• Algú més treballa en la mateixa app.
• Vols que algú revisi el canvi abans que arribi a producció.

Quan la feina està acabada i provada, es fusiona de nou a la branca principal. A GitHub, això normalment passa mitjançant una pull request, una pàgina que mostra els canvis per revisar-los. Si el teu constructor només sincronitza una branca, un desenvolupador pot gestionar les branques des de GitHub.

Pas 5: desfés amb seguretat

Quan una petició trenca l’app, resisteix la temptació de demanar-ne cinc més a sobre. Torna a l’última versió bona i prova una petició més clara.

• Al constructor: fes servir el seu punt de control o la funció de restaurar, si en té.
• A Git: git revert crea un commit nou que desfà un d’antic i manté l’historial intacte. És l’opció segura per al codi que altres persones puguin haver baixat.
• Evita git push --force en una branca compartida, tret que sàpigues exactament per què. Reescriu l’historial per a tothom.

Si no n’estàs segur, pregunta:

El darrer canvi ha trencat la pàgina d’inici de sessió. Mostra’m quins fitxers ha canviat respecte del commit anterior i explica què feia cada canvi. No canviïs res encara.

Pas 6: fes pull abans de demanar canvis

Si un desenvolupador o una altra eina canvia el codi a GitHub, el constructor d’IA no ho sap fins que no hi fas pull d’aquests canvis. Demanar canvis sobre codi antic provoca conflictes i pèrdua de feina.

• Fes pull a l’inici de cada sessió.
• Acordeu qui edita què, i eviteu que els dos editeu els mateixos fitxers al mateix temps.
• Si tens un conflicte de fusió (dos canvis a les mateixes línies), demana al desenvolupador o a la IA que el resolgui i que n’expliqui la decisió.

Exemples de peticions

Abans de començar: què ha canviat al repositori des de la meva darrera sessió? Resumeix els commits.

Fes el següent canvi per separat: afegeix un botó «Duplica» a cada factura. No canviïs res més, perquè pugui fer-ne el commit a part.

Comprova que cap clau d’API, contrasenya o fitxer .env estigui seguit per Git, inclosos els commits antics. Informa només dels noms dels fitxers, no dels valors.

Errors habituals

• Fer commit de secrets. Quan una clau és a l’historial de Git, queda exposada encara que després n’esborris el fitxer. Renova-la.
• Un commit gegant a la setmana. No pots desfer un canvi sense desfer-los tots.
• Missatges com «update». L’historial deixa de servir per trobar què s’ha trencat.
• Demanar canvis sobre codi antic. Fes pull primer quan algú més està editant.
• Fer force push per corregir un error. Pot esborrar la feina d’altres. Millor reverteix.
• Fer commit de node_modules. És enorme i de totes maneres es recrea a partir del fitxer de bloqueig.

Llista de comprovació

• El projecte està connectat a un repositori privat.
• .gitignore exclou .env, node_modules, la sortida de la compilació i els secrets.
• Faig commit després de cada canvi que funciona.
• Els missatges de commit diuen què ha canviat en una línia.
• Els canvis grans o arriscats van en una branca i es revisen.
• Faig pull abans de demanar canvis quan algú més edita el codi.
• Desfaig amb punts de control o amb git revert, no amb force push.
• Qualsevol clau que s’hagi pujat alguna vegada s’ha renovat.

Git a Mythex

Mythex desa un punt de control de Git després de cada torn de l’agent que hagi funcionat, i Torna a aquest punt reverteix el projecte fins a aquell moment: el desfer des del constructor que descriu el pas 5. Consulta Itera sense reconstruir.

Al Pro, la sincronització amb GitHub connecta un repositori des de la configuració del projecte perquè puguis fer push i pull, i l’exportació descarrega el projecte sense els secrets ni node_modules. Consulta GitHub, exportació i importació. Connectar GitHub abans de passar un projecte a un desenvolupador simplifica molt el traspàs: vegeu com treballar amb un desenvolupador en una app creada amb IA i com exportar i allotjar pel teu compte una app creada amb IA.

Preguntes