Comment utiliser Git avec une application créée par IA

Pour utiliser Git avec une application créée par IA, reliez le projet à un dépôt Git, faites un commit après chaque modification qui fonctionne, rédigez un message d'une ligne qui décrit ce qui a changé et gardez les secrets hors du dépôt grâce à un .gitignore. Utilisez une branche pour tout ce qui est risqué, faites un pull avant de formuler une nouvelle demande si quelqu'un d'autre a modifié le code, et quand l'IA casse quelque chose, revenez au dernier commit qui fonctionnait au lieu de continuer à demander des corrections par-dessus le problème.

Git est un système de gestion de versions : un historique de chaque version enregistrée de votre code. GitHub est un site qui héberge des dépôts Git en ligne. Si ces notions vous sont nouvelles, commencez par ce qu'est GitHub. Ce guide porte sur les bonnes habitudes qui rendent Git utile quand une IA écrit l'essentiel du code.

Pourquoi Git compte encore plus avec l'IA

Une IA peut modifier vingt fichiers en un seul tour. C'est rapide, mais une seule demande peut aussi casser discrètement ce qui fonctionnait la veille. Git vous offre :

• Un moyen de revenir en arrière. Toute version commitée peut être restaurée.
• Un historique des modifications. Vous voyez exactement quels fichiers et quelles lignes une demande a touchés.
• Une copie en dehors du générateur. Votre code se trouve à un endroit que vous contrôlez.
• Un transfert standard. Tout développeur, hébergeur ou outil peut travailler à partir d'un dépôt Git.

Étape 1 : relier un dépôt

Créez un dépôt (en général privé) sur GitHub ou un service similaire, puis reliez votre projet à ce dépôt. La plupart des générateurs d'apps IA compatibles avec Git le font depuis une page de paramètres, avec un bouton « Connecter GitHub ». Si le vôtre ne le propose pas, vous pouvez exporter le code et le pousser vous-même, ou demander à un développeur de le configurer une seule fois.

Avant le premier push, assurez-vous que le dépôt ignore ce qui ne doit pas s'y trouver :

Vérifie le fichier .gitignore. Assure-toi qu'il exclut les fichiers .env, node_modules, les dossiers de build et tout fichier contenant des secrets. Dis-moi ce que tu as ajouté.

Étape 2 : commiter après chaque modification qui fonctionne

Un commit est un instantané enregistré avec un message. L'habitude qui compte : commitez quand quelque chose fonctionne, avant de demander la suite.

1. Formulez une demande pour une seule modification.
2. Vérifiez le résultat dans l'aperçu.
3. Si cela fonctionne, faites un commit (ou une synchronisation) avec un message.
4. Passez ensuite à la suite.

Avec de petits commits, quand quelque chose casse, vous savez quelle modification en est responsable, et l'annuler ne supprime pas le reste de votre travail.

Étape 3 : rédiger des messages que vous comprendrez plus tard

Un bon message dit ce qui a changé et pourquoi, en une ligne :

• Bien : Ajouter l'export CSV sur la page des commandes
• Bien : Corriger le formulaire de réservation qui refuse les horaires après 18 h
• Inutile : update, changements, corrections diverses

Vous pouvez demander à l'IA de les rédiger :

Résume les modifications depuis le dernier commit en une seule ligne, qui commence par un verbe et fait moins de 70 caractères.

Étape 4 : utiliser des branches pour le travail risqué

Une branche est une ligne de travail séparée. Vous pouvez tester quelque chose sur une branche et, si cela ne donne rien, l'abandonner sans toucher à la version principale.

Utilisez une branche quand :

• la modification est importante (refonte, nouveau parcours de paiement, changement de base de données) ;
• quelqu'un d'autre travaille sur la même application ;
• vous voulez qu'une personne relise la modification avant sa mise en ligne.

Une fois le travail terminé et testé, il est fusionné dans la branche principale. Sur GitHub, cela se fait en général via une pull request, une page qui présente les modifications pour relecture. Si votre générateur ne synchronise qu'une seule branche, un développeur peut gérer les branches côté GitHub.

Étape 5 : annuler en toute sécurité

Quand une demande casse l'application, résistez à l'envie de formuler cinq demandes supplémentaires par-dessus. Revenez à la dernière bonne version et essayez une demande plus claire.

• Dans le générateur : utilisez sa fonction de point de restauration ou de restauration, si elle existe.
• Dans Git : git revert crée un nouveau commit qui annule un ancien, et conserve l'historique intact. C'est le choix sûr pour du code que d'autres ont peut-être déjà récupéré.
• Évitez git push --force sur une branche partagée, sauf si vous savez exactement pourquoi. Cela réécrit l'historique pour tout le monde.

En cas de doute, demandez :

La dernière modification a cassé la page de connexion. Montre-moi quels fichiers elle a changés par rapport au commit précédent, et explique ce que faisait chaque modification. Ne change rien pour l'instant.

Étape 6 : faire un pull avant de formuler une demande

Si un développeur ou un autre outil modifie le code sur GitHub, le générateur d'apps IA ne le sait pas tant que vous n'avez pas tiré (pull) ces modifications. Formuler une demande sur un code périmé provoque des conflits et des pertes de travail.

• Faites un pull au début de chaque session.
• Définissez qui modifie quoi, et évitez que les deux parties modifient les mêmes fichiers en même temps.
• Si vous obtenez un conflit de fusion (deux modifications sur les mêmes lignes), demandez au développeur ou à l'IA de le résoudre et d'expliquer le choix retenu.

Exemples de demandes

Avant de commencer : qu'est-ce qui a changé dans le dépôt depuis ma dernière session ? Résume les commits.

Fais la prochaine modification de façon isolée : ajoute un bouton « Dupliquer » à chaque facture. Ne change rien d'autre, pour que je puisse la commiter séparément.

Vérifie qu'aucune clé d'API, aucun mot de passe ni aucun fichier .env n'est suivi par Git, y compris dans les anciens commits. Indique seulement les noms des fichiers, sans les valeurs.

Erreurs courantes

• Commiter des secrets. Une fois qu'une clé est dans l'historique Git, elle est exposée, même après suppression du fichier. Régénérez-la.
• Un seul gros commit par semaine. Impossible d'annuler une modification sans annuler toutes les autres.
• Des messages comme « update ». L'historique devient inutile pour trouver ce qui a cassé.
• Formuler une demande sur un code périmé. Faites un pull d'abord si quelqu'un d'autre modifie le code.
• Forcer un push pour corriger une erreur. Cela peut effacer le travail d'autres personnes. Préférez revert.
• Commiter node_modules. C'est très lourd, et le dossier est de toute façon recréé à partir du fichier de verrouillage.

Liste de vérification

• Le projet est relié à un dépôt privé.
• .gitignore exclut .env, node_modules, les fichiers de build et les secrets.
• Je fais un commit après chaque modification qui fonctionne.
• Les messages de commit décrivent ce qui a changé en une ligne.
• Les modifications importantes ou risquées passent par une branche et sont relues.
• Je fais un pull avant de formuler une demande quand quelqu'un d'autre modifie le code.
• J'annule avec les points de restauration ou git revert, jamais avec un force push.
• Toute clé qui a été commitée a été régénérée.

Git sur Mythex

Mythex enregistre un point de restauration Git après chaque tour réussi de l'agent, et Revenir à ce point restaure le projet à ce moment-là : c'est l'annulation côté générateur décrite à l'étape 5. Voir Itérer sans reconstruire.

Sur Pro, la synchronisation GitHub relie un dépôt depuis les paramètres du projet, afin que vous puissiez pousser et tirer les modifications, et l'export télécharge le projet sans les secrets ni node_modules. Voir GitHub, export et import. Connecter GitHub avant de confier un projet à un développeur simplifie beaucoup la passation : voir comment travailler avec un développeur sur une application créée par IA et comment exporter et auto-héberger une application créée par IA.

Questions