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

Pour utiliser Git avec une app créée par IA, reliez le projet à un dépôt Git, faites un commit après chaque modification qui fonctionne, écrivez un message d'une ligne qui décrit ce qui a changé, et gardez les secrets hors du dépôt avec un .gitignore. Utilisez une branche pour tout ce qui est risqué, faites un pull avant de faire une nouvelle requête si quelqu'un d'autre a modifié le code, et quand l'IA casse quelque chose, revenez au dernier commit fonctionnel au lieu de faire une requête par-dessus le problème.

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

Pourquoi Git est encore plus important avec l'IA

Une IA peut modifier vingt fichiers en un seul tour. C'est rapide, mais une seule requête peut aussi casser discrètement ce qui fonctionnait hier. Git vous donne :

• Un moyen de revenir en arrière. Toute version committée peut être restaurée.
• Un registre des modifications. Vous voyez exactement quels fichiers et quelles lignes une requête 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 (généralement privé) sur GitHub ou un service similaire, et reliez votre projet à ce dépôt. La plupart des générateurs d'apps IA qui prennent en charge Git le font depuis une page de paramètres, avec un bouton « Connecter GitHub ». Si le vôtre ne le fait pas, vous pouvez exporter le code et le transférer vous-même, ou demander à un développeur de configurer cela 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 : Faire un commit après chaque modification qui fonctionne

Un commit est une sauvegarde instantanée accompagnée d'un message. L'habitude qui compte : faites un commit quand quelque chose fonctionne, avant de demander la prochaine chose.

1. Faites une requête pour une seule modification.
2. Vérifiez-la dans l'aperçu.
3. Si ça fonctionne, faites un commit (ou une synchronisation) avec un message.
4. Passez ensuite à la suite.

De petits commits signifient que lorsque quelque chose casse, vous savez quelle modification en est la cause, et l'annuler ne supprime pas le reste de votre travail.

Étape 3 : Écrire des messages que vous pourrez relire plus tard

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

• Bien : Ajouter l'export CSV à la page des commandes
• Bien : Corriger le formulaire de réservation qui refuse les heures après 18 h
• Peu utile : 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, en commençant par un verbe, en moins de 70 caractères.

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

Une branche est une ligne de travail distincte. Vous pouvez essayer quelque chose sur une branche et, si ça ne donne rien, l'abandonner sans toucher à la version principale.

Utilisez une branche quand :

• La modification est importante (une refonte, un nouveau parcours de paiement, un changement de base de données).
• Quelqu'un d'autre travaille sur la même app.
• Vous voulez qu'une personne examine la modification avant la 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 par une pull request, une page qui présente les modifications pour révision. Si votre générateur ne synchronise qu'une seule branche, un développeur peut gérer les branches du côté de GitHub.

Étape 5 : Revenir en arrière en toute sécurité

Quand une requête casse l'app, résistez à l'envie de faire cinq autres requêtes par-dessus. Revenez à la dernière bonne version et essayez une requête plus claire.

• Dans le générateur : utilisez sa fonction de point de sauvegarde ou de restauration, s'il en a une.
• Dans Git : git revert crée un nouveau commit qui annule un ancien commit, en conservant l'historique intact. C'est le choix sûr pour un code que d'autres ont 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 changement. Ne change rien pour l'instant.

Étape 6 : Faire un pull avant de faire une requête

Si un développeur ou un autre outil modifie le code sur GitHub, le générateur IA ne le sait pas tant que vous ne récupérez pas ces modifications (pull). Faire une requête sur un ancien code entraîne des conflits et une perte de travail.

• Faites un pull au début de chaque session.
• Convenez de qui modifie quoi, et évitez que les deux côtés 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 fait.

Exemples de requêtes

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 seule : ajoute un bouton « Dupliquer » à chaque facture. Ne change rien d'autre, pour que je puisse la committer 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 commits passés. Ne signale que les noms de fichiers, pas les valeurs.

Erreurs courantes

• Committer des secrets. Une fois qu'une clé se trouve dans l'historique Git, elle est exposée, même si vous supprimez le fichier ensuite. Changez-la.
• Un énorme commit par semaine. Vous ne pouvez pas annuler une seule modification sans annuler toutes les autres.
• Des messages comme « update ». L'historique devient inutile pour trouver ce qui a cassé.
• Faire une requête 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. Faites plutôt un revert.
• Committer node_modules. C'est énorme, et ce 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 révisées.
• Je fais un pull avant de faire une requête quand quelqu'un d'autre modifie le code.
• J'annule avec les points de sauvegarde ou git revert, jamais avec un force-push.
• Toute clé qui a déjà été committée a été changée.

Git sur Mythex

Mythex enregistre un point de sauvegarde Git après chaque tour réussi de l'agent, et Revenir à ce point ramène le projet à cet état. 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 pour que vous puissiez faire des push et des pull avec lui, et l'export télécharge le projet en excluant les secrets et node_modules. Voir GitHub, export et import. Relier GitHub avant de confier un projet à un développeur simplifie beaucoup le transfert. Voir comment travailler avec un développeur sur une app créée par IA et comment exporter et héberger soi-même une app créée par IA.

Questions