Git integrado
Un proyecto Restorm está hecho para vivir en un repositorio git. La integración va más allá de
un simple git commit: comprende el formato y sabe resolver un conflicto al nivel de las
entidades de negocio, no de las líneas de YAML.
Puesta en marcha
Section titled “Puesta en marcha”No hay nada que configurar. En cuanto el archivo .restorm abierto se encuentra en un
repositorio git, las superficies de git se activan.
Restorm utiliza su git local: no hay que introducir credenciales ni gestionar tokens en la
aplicación. La regla es simple: si git push funciona en su terminal, funciona en Restorm.
Git se lanza con las solicitudes interactivas desactivadas: un repositorio que pidiera una
contraseña falla de inmediato con el mensaje de git, en lugar de bloquear la interfaz.
La celda GIT de la barra de estado
Section titled “La celda GIT de la barra de estado”Dos botones, Subir y Descargar, cada uno con una marca (un punto, nunca un número) cuando hay algo que enviar o una versión más reciente que descargar.
El menú Git de la barra de título ofrece las mismas acciones, más Actualizar, Restablecer a la versión del servidor e Historial.
La ventana modal de subida muestra un mensaje de commit ya redactado, generado de forma determinista a partir del diff estructural, sin ningún modelo de lenguaje. Una línea por entidad modificada (petición, escenario, carpeta, carpeta de variables), nunca una línea por campo.
- Un selector de idioma del mensaje, independiente del idioma de la interfaz, con un interruptor para convertirlo en el valor por defecto.
- Un título editable, con un contador indicativo en 72 caracteres.
- Un cuerpo de varias líneas.
Al validar se encadena: guardar, git add, commit, push.
Descargar
Section titled “Descargar”Restorm guarda primero y después descarga y fusiona.
Fusión limpia: el árbol y las pestañas abiertas se actualizan en el sitio.
Conflicto: se abre una vista de resolución de cuatro paneles.
| Panel | Contenido |
|---|---|
| Lista de conflictos | Las entidades en conflicto |
| Su versión | En modo de solo lectura |
| La versión de ellos | En modo de solo lectura |
| Resuelto | Editable: es lo que se escribirá |
El punto importante: cada panel muestra la entidad en su verdadero editor, una petición HTTP
en el editor HTTP, un escenario en el editor de escenarios. No resuelve marcadores <<<<<<< en
YAML, compara dos peticiones.
Hay un botón «usar esta versión» por cada lado, y los campos que divergen se resaltan en rojo; cuando solo un campo difiere, el panel se abre directamente en la pestaña correspondiente.
La documentación de API de una carpeta de variables se resuelve automáticamente (prevalece la versión más reciente).
Cancelar ejecuta un git merge --abort. Si cierra la aplicación en plena resolución, en el
siguiente arranque se le propondrá abandonar la fusión.
Comprobación de fondo (semi-pull)
Section titled “Comprobación de fondo (semi-pull)”Restorm comprueba periódicamente si existe una versión más reciente, sin fusionar nunca por sí
solo. Tres disparadores: una modificación observada en .git, la apertura de un archivo y un
temporizador cuya frecuencia se ajusta en Ajustes ▸ Git (Off, 15 min, 30 min, 1 h, 4 h,
12 h, 24 h).
Una notificación «Actualización disponible» ofrece entonces Pull now.
Modificación externa del archivo
Section titled “Modificación externa del archivo”Si el archivo ha cambiado en el disco desde que se abrió, el guardado se rechaza y Restorm le pide Recargar o Conservar su versión.
Por qué los diffs son legibles
Section titled “Por qué los diffs son legibles”Dos propiedades del formato, descritas en
Proyectos y archivos .restorm: un orden de
claves canónico e identificadores derivados de forma estable.
Consecuencia: abrir y volver a guardar sin cambiar nada no produce ningún diff, y dos personas que añaden la misma petición en el mismo lugar producen entidades que la fusión sabe emparejar.
Historial
Section titled “Historial”Git ▸ Historial abre una vista de dos paneles: la lista de commits con un canal de ramas, y el detalle a la derecha. El menú contextual de un commit permite recuperar esa versión.
Por MCP
Section titled “Por MCP”Cuatro herramientas, en edición Pro: git_commit_push (paso 1 de 2 — devuelve un token de
revisión, el título, el cuerpo y el diff por entidad, sin escribir nada),
git_confirm_push (paso 2 de 2 — se rechaza si el proyecto ha cambiado desde la revisión),
git_pull y git_resolve_conflicts.
La división en dos pasos es deliberada: un agente no puede subir nada sin que antes se haya presentado un diff.