Git integrato
Un progetto Restorm è fatto per vivere in un repository git. L’integrazione va più
lontano di un semplice git commit: comprende il formato e sa risolvere
un conflitto a livello delle entità applicative, non delle righe di YAML.
Non c’è nulla da configurare. Appena il file .restorm aperto si trova in
un repository git, le superfici git si attivano.
Restorm usa il git locale: non ci sono credenziali da inserire né gestione di
token nell’applicazione. La regola è semplice — se git push funziona nel
terminale, funziona in Restorm. Git viene lanciato con i prompt
disattivati: un repository che chiedesse una password fallisce immediatamente
con il messaggio di git, anziché bloccare l’interfaccia.
La cella GIT della barra di stato
Section titled “La cella GIT della barra di stato”Due pulsanti, Push e Fetch, ciascuno con una pastiglia (un punto, mai un numero) quando c’è qualcosa da inviare o una versione più recente da recuperare.
Il menu Git della barra del titolo offre le stesse azioni, più Aggiorna, Reimposta sulla versione del server e Cronologia.
La finestra modale di push mostra un messaggio di commit già redatto, generato in modo deterministico a partire dal diff strutturale — senza alcun modello di linguaggio. Una riga per entità modificata (richiesta, scenario, cartella, cartella di variabili), mai una riga per campo.
- Un selettore di lingua del messaggio, indipendente dalla lingua dell’interfaccia, con un interruttore per renderlo il valore predefinito.
- Un titolo modificabile, con un contatore indicativo a 72 caratteri.
- Un corpo su più righe.
Confermando si concatena: salvataggio, git add, commit, push.
Restorm salva prima, poi recupera e fonde.
Fusione pulita: l’albero e le schede aperte si aggiornano in loco.
Conflitto: si apre una vista di risoluzione a quattro pannelli.
| Pannello | Contenuto |
|---|---|
| Elenco dei conflitti | Le entità in conflitto |
| La propria versione | In sola lettura |
| La loro versione | In sola lettura |
| Risolto | Modificabile — è ciò che verrà scritto |
Il punto importante: ogni pannello mostra l’entità nel suo vero
editor — una richiesta HTTP nell’editor HTTP, uno scenario nell’editor di
scenari. Non si risolvono marcatori <<<<<<< in un file YAML, si
confrontano due richieste.
C’è un pulsante «usa questa versione» per lato, e i campi che divergono sono evidenziati in rosso — quando differisce un solo campo, il pannello si apre direttamente sulla scheda interessata.
La documentazione di API di una cartella di variabili si risolve automaticamente (prevale la versione più recente).
Annulla esegue un git merge --abort. Chiudere l’applicazione in piena
risoluzione fa proporre, al lancio successivo, di abbandonare la fusione.
Verifica in background (semi-pull)
Section titled “Verifica in background (semi-pull)”Restorm verifica periodicamente se esiste una versione più recente — senza
mai fondere da solo. Tre inneschi: una modifica osservata
in .git, l’apertura di un file e un timer la cui frequenza si imposta
in Impostazioni ▸ Git (Off, 15 min, 30 min, 1 h, 4 h, 12 h, 24 h).
Una notifica «Aggiornamento disponibile» propone allora Pull now.
Modifica esterna del file
Section titled “Modifica esterna del file”Se il file è cambiato sul disco dopo la sua apertura, il salvataggio viene rifiutato e Restorm chiede di Ricaricare o di Mantenere la propria versione.
Perché i diff sono leggibili
Section titled “Perché i diff sono leggibili”Due proprietà del formato, descritte in
Progetti e file .restorm:
un ordine canonico delle chiavi e identificatori derivati in modo stabile.
Conseguenza: aprire e poi salvare di nuovo senza modificare nulla non produce alcun diff, e due persone che aggiungono la stessa richiesta nello stesso punto producono entità che la fusione sa appaiare.
Cronologia
Section titled “Cronologia”Git ▸ Cronologia apre una vista a due riquadri: l’elenco dei commit con una canaletta dei rami, e il dettaglio a destra. Il menu contestuale di un commit permette di recuperare quella versione.
Tramite MCP
Section titled “Tramite MCP”Quattro strumenti, in edizione Pro: git_commit_push (fase 1 di 2 — restituisce un
token di revisione, il titolo, il corpo e il diff per entità, senza scrivere
nulla), git_confirm_push (fase 2 di 2 — rifiutata se il progetto è cambiato
dopo la revisione), git_pull e git_resolve_conflicts.
La suddivisione in due fasi è deliberata: un agente non può eseguire un push senza che un diff sia stato presentato prima.