Git intégré
Un projet Restorm est fait pour vivre dans un dépôt git. L’intégration va plus
loin qu’un simple git commit : elle comprend le format et sait résoudre
un conflit au niveau des entités métier, pas des lignes de YAML.
Mise en route
Section titled “Mise en route”Il n’y a rien à configurer. Dès que le fichier .restorm ouvert se trouve dans
un dépôt git, les surfaces git s’activent.
Restorm utilise votre git local : ni identifiants à saisir, ni gestion de
jetons dans l’application. La règle est simple — si git push fonctionne dans
votre terminal, il fonctionne dans Restorm. Git est lancé avec les invites
désactivées : un dépôt qui demanderait un mot de passe échoue immédiatement
avec le message de git, plutôt que de bloquer l’interface.
La cellule GIT de la barre d’état
Section titled “La cellule GIT de la barre d’état”Deux boutons, Pousser et Récupérer, chacun portant une pastille (un point, jamais un nombre) quand il y a quelque chose à envoyer ou une version plus récente à récupérer.
Le menu Git de la barre de titre offre les mêmes actions, plus Rafraîchir, Réinitialiser sur la version du serveur et Historique.
Pousser
Section titled “Pousser”La modale de push affiche un message de commit déjà rédigé, généré déterministiquement à partir du diff structurel — sans modèle de langage. Une ligne par entité modifiée (requête, scénario, dossier, dossier de variables), jamais une ligne par champ.
- Un sélecteur de langue du message, indépendant de la langue de l’interface, avec un interrupteur pour en faire la valeur par défaut.
- Un titre éditable, avec un compteur indicatif à 72 caractères.
- Un corps multiligne.
Valider enchaîne : enregistrer, git add, commit, push.
Récupérer
Section titled “Récupérer”Restorm enregistre d’abord, puis récupère et fusionne.
Fusion propre : l’arbre et les onglets ouverts se rafraîchissent en place.
Conflit : une vue de résolution à quatre panneaux s’ouvre.
| Panneau | Contenu |
|---|---|
| Liste des conflits | Les entités en conflit |
| Votre version | En lecture seule |
| Leur version | En lecture seule |
| Résolu | Éditable — c’est ce qui sera écrit |
Le point important : chaque panneau affiche l’entité dans son véritable
éditeur — une requête HTTP dans l’éditeur HTTP, un scénario dans l’éditeur de
scénarios. Vous ne résolvez pas des marqueurs <<<<<<< dans du YAML, vous
comparez deux requêtes.
Un bouton « utiliser cette version » par côté, et les champs qui divergent sont surlignés en rouge — quand un seul champ diffère, le panneau s’ouvre directement sur l’onglet concerné.
La documentation d’API d’un dossier de variables se résout automatiquement (la version la plus récente l’emporte).
Annuler exécute un git merge --abort. Fermer l’application en pleine
résolution vous fait proposer, au lancement suivant, d’abandonner la fusion.
Vérification de fond (semi-pull)
Section titled “Vérification de fond (semi-pull)”Restorm vérifie périodiquement s’il existe une version plus récente — sans
jamais fusionner tout seul. Trois déclencheurs : une modification observée
dans .git, l’ouverture d’un fichier, et un minuteur dont la fréquence se règle
dans Paramètres ▸ Git (Off, 15 min, 30 min, 1 h, 4 h, 12 h, 24 h).
Une notification « Mise à jour disponible » propose alors Pull now.
Modification externe du fichier
Section titled “Modification externe du fichier”Si le fichier a changé sur le disque depuis son ouverture, l’enregistrement est refusé et Restorm vous demande de Recharger ou de Garder votre version.
Pourquoi les diffs sont lisibles
Section titled “Pourquoi les diffs sont lisibles”Deux propriétés du format, décrites dans
Projets et fichiers .restorm :
un ordre de clés canonique, et des identifiants dérivés de façon stable.
Conséquence : ouvrir puis réenregistrer sans rien modifier ne produit aucun diff, et deux personnes qui ajoutent la même requête au même endroit produisent des entités que la fusion sait apparier.
Historique
Section titled “Historique”Git ▸ Historique ouvre une vue à deux volets : la liste des commits avec une gouttière de branches, et le détail à droite. Le menu contextuel d’un commit permet de récupérer cette version.
Par MCP
Section titled “Par MCP”Quatre outils, en édition Pro : git_commit_push (étape 1 sur 2 — renvoie un
jeton de revue, le titre, le corps et le diff par entité, sans rien
écrire), git_confirm_push (étape 2 sur 2 — refusée si le projet a changé
depuis la revue), git_pull et git_resolve_conflicts.
Le découpage en deux étapes est délibéré : un agent ne peut pas pousser sans qu’un diff ait été présenté d’abord.