Innebygd git

Et Restorm-prosjekt er laget for å leve i et git-depot. Integrasjonen går lenger enn en enkel git commit: den forstår formatet og kan løse en konflikt på nivået til forretningsentitetene, ikke YAML-linjene.

Pro-utgaven

Git-integrasjonen er inkludert i Pro- og Enterprise-utgavene. Se Planer og muligheter.

Komme i gang

Det er ingenting å sette opp. Så snart den åpnede .restorm-filen ligger i et git-depot, aktiveres git-flatene.

Restorm bruker din lokale git: ingen påloggingsdetaljer å skrive inn, ingen tokener å håndtere i programmet. Regelen er enkel — virker git push i terminalen din, virker den i Restorm. Git startes med spørsmålsdialogene avskrudd: et depot som ville bedt om et passord, feiler umiddelbart med git-meldingen sin, i stedet for å låse grensesnittet.

GIT-cellen i statuslinjen

To knapper, Push og Hent, hver med en markør (et punkt, aldri et tall) når det er noe å sende eller en nyere versjon å hente.

Git-menyen i tittellinjen tilbyr de samme handlingene, i tillegg til Oppdater, Tilbakestill til serverens versjon og Historikk.

Push

Push-dialogen viser en commit-melding som allerede er skrevet, generert deterministisk ut fra den strukturelle diffen — uten språkmodell. Én linje per endret entitet (forespørsel, scenario, mappe, miljømappe), aldri én linje per felt.

• En språkvelger for meldingen, uavhengig av språket i grensesnittet, med en bryter for å gjøre valget til standardverdi.
• En redigerbar tittel, med en veiledende teller på 72 tegn.
• En kropp over flere linjer.

Når du bekrefter, skjer alt på rad: lagre, git add, commit, push.

Hent

Restorm lagrer først, henter så og slår sammen.

Ren sammenslåing: treet og de åpne fanene oppdateres på plass.

Konflikt: en løsevisning med fire paneler åpnes.

Panel	Innhold
Liste over konflikter	Entitetene som står i konflikt
Din versjon	Skrivebeskyttet
Serverversjon	Skrivebeskyttet
Løst	Redigerbar — det er dette som blir skrevet

Det viktige poenget: hvert panel viser entiteten i sin virkelige editor — en HTTP-forespørsel i HTTP-editoren, et scenario i scenarioeditoren. Du løser ikke <<<<<<<-markører i YAML, du sammenligner to forespørsler.

Én knapp merket «bruk denne versjonen» per side, og feltene som avviker er uthevet i rødt — når bare ett felt skiller seg, åpnes panelet direkte på den aktuelle fanen.

API-dokumentasjonen til en miljømappe løses automatisk (den nyeste versjonen vinner).

Avbryt kjører en git merge --abort. Lukker du programmet midt i en løsing, får du tilbud om å forkaste sammenslåingen ved neste oppstart.

Bakgrunnssjekk (semi-pull)

Restorm sjekker med jevne mellomrom om det finnes en nyere versjon — uten noen gang å slå sammen av seg selv. Tre utløsere: en endring observert i .git, at en fil åpnes, og en tidsutløser du stiller frekvensen på i Innstillinger ▸ Git (Off, 15 min, 30 min, 1 t, 4 t, 12 t, 24 t).

Et varsel merket «Oppdatering tilgjengelig» tilbyr da Pull now.

Filen endret utenfra

Har filen endret seg på disken etter at den ble åpnet, blir lagringen nektet og Restorm ber deg om å Last inn på nytt eller Behold min versjon.

Hvorfor diffene er lesbare

To egenskaper ved formatet, beskrevet i Prosjekter og .restorm-filer: en kanonisk nøkkelrekkefølge, og identifikatorer som utledes stabilt.

Følgen er at det å åpne og lagre på nytt uten å endre noe ikke gir noen diff, og at to personer som legger til den samme forespørselen på samme sted, produserer entiteter som sammenslåingen klarer å parre.

Historikk

Git ▸ Historikk åpner en visning med to paneler: listen over commiter med en grenrenne, og detaljene til høyre. Kontekstmenyen til en commit lar deg hente tilbake den versjonen.

Via MCP

Fire verktøy, i Pro-utgaven: git_commit_push (trinn 1 av 2 — returnerer et gjennomgangstoken, tittelen, kroppen og diffen per entitet, uten å skrive noe), git_confirm_push (trinn 2 av 2 — nektes hvis prosjektet har endret seg siden gjennomgangen), git_pull og git_resolve_conflicts.

Oppdelingen i to trinn er tilsiktet: en agent kan ikke pushe uten at en diff har blitt lagt fram først.