Aller au contenu principal

Règles Git

Statut​

Document de règles projet — version initiale.

Objectif​

Définir des conventions Git simples pour préserver la traçabilité, réduire les risques et faciliter le travail humain ou agentique.

Règles strictes​

  • Ne pas commit sans demande explicite.
  • Ne pas créer de branche sans demande explicite.
  • Ne pas réécrire l'historique partagé sans validation.
  • Ne pas inclure de secrets dans un commit.
  • Ne pas mélanger changements de code et documentation hors périmètre.
  • Ne pas corriger des sujets non liés dans le même changement.
  • Vérifier le diff avant livraison.

Bonnes pratiques​

  • Un changement = une intention claire.
  • Commits petits et cohérents.
  • Message de commit explicite.
  • Tests ou contrôles mentionnés dans la PR.
  • Fichiers générés exclus sauf nécessité.
  • Migrations et code applicatif liés dans le même changement si dépendants.

Branches​

La stratégie de branches officielle reste à confirmer.

Vision cible simple :

  • main pour code stable ;
  • branche feature courte ;
  • branche hotfix si incident ;
  • protection production ;
  • review avant merge.

Pull requests​

Une PR devrait préciser :

  • objectif ;
  • périmètre ;
  • fichiers majeurs modifiés ;
  • tests réalisés ;
  • risques ;
  • migrations éventuelles ;
  • impact docs.

Règles pour agents IA​

Un agent doit :

  • inspecter git status avant et après ;
  • limiter les changements au périmètre ;
  • ne pas supprimer du travail non demandé ;
  • ne pas formater tout le projet par réflexe ;
  • signaler les fichiers non suivis pertinents.

Anti-patterns​

  • Commit massif sans thème.
  • Refactor opportuniste dans une correction simple.
  • Secrets dans .env.
  • Modification de lockfile sans dépendance réelle.
  • Suppression de fichiers non compris.
  • PR sans contrôle ni explication.

Points à clarifier​

  • Convention de nom de branche.
  • Convention de messages commit.
  • Règles de review.
  • CI obligatoire.
  • Gestion des releases.