Indbygget Git

Et Restorm-projekt er lavet til at leve i et git-repositorium. Integrationen går længere end en simpel git commit: den forstår formatet og kan løse en konflikt på niveau med de forretningsmæssige enheder, ikke med YAML-linjer.

Pro-udgaven

Git-integrationen er inkluderet i udgaverne Pro og Enterprise. Se Planer og kapaciteter.

Kom i gang

Der er ikke noget at konfigurere. Så snart den åbne .restorm-fil ligger i et git-repositorium, aktiveres git-fladerne.

Restorm bruger din lokale git: ingen legitimationsoplysninger at indtaste, ingen håndtering af tokens i applikationen. Reglen er enkel — virker git push i din terminal, virker det i Restorm. Git startes med prompts slået fra: et repositorium, der ville bede om en adgangskode, fejler med det samme med gits egen besked frem for at låse brugerfladen.

GIT-cellen i statuslinjen

To knapper, Push og Hent, som hver bærer en prik (et punkt, aldrig et tal), når der er noget at sende eller en nyere version at hente.

Menuen Git i titellinjen tilbyder de samme handlinger plus Opdater, Nulstil til serverens version og Historik.

Push

Push-dialogen viser en allerede skrevet commit-besked, som genereres deterministisk ud fra det strukturelle diff — uden nogen sprogmodel. Én linje pr. ændret enhed (anmodning, scenarie, mappe, miljømappe), aldrig én linje pr. felt.

• En sprogvælger til beskeden, uafhængig af brugerfladens sprog, med en knap til at gøre det til standardværdien.
• En redigerbar titel med en vejledende tæller ved 72 tegn.
• En flerlinjet brødtekst.

Bekræfter du, kører kæden: gem, git add, commit, push.

Hent

Restorm gemmer først og henter og fletter derefter.

Ren fletning: træstrukturen og de åbne faner opdateres på stedet.

Konflikt: en løsningsvisning med fire paneler åbnes.

Panel	Indhold
Konfliktliste	De enheder, der er i konflikt
Din version	Skrivebeskyttet
Deres version	Skrivebeskyttet
Løst	Redigerbart — det er dette, der bliver skrevet

Det vigtige punkt: hvert panel viser enheden i dens rigtige editor — en HTTP-anmodning i HTTP-editoren, et scenarie i scenarieeditoren. Du løser ikke <<<<<<<-markører i YAML, du sammenligner to anmodninger.

Der er en »brug denne version«-knap pr. side, og de felter, der afviger, fremhæves med rødt — afviger kun ét felt, åbner panelet direkte på den pågældende fane.

API-dokumentationen for en miljømappe løses automatisk (den nyeste version vinder).

Annullér kører et git merge --abort. Lukker du applikationen midt i en løsning, får du ved næste start tilbudt at opgive fletningen.

Baggrundskontrol (semi-pull)

Restorm ser med jævne mellemrum efter, om der findes en nyere version — uden nogensinde at flette af sig selv. Tre udløsere: en observeret ændring i .git, åbningen af en fil og en timer, hvis frekvens indstilles under Indstillinger ▸ Git (Off, 15 min., 30 min., 1 t., 4 t., 12 t., 24 t.).

En notifikation, »Opdatering tilgængelig«, tilbyder så Pull now.

Ekstern ændring af filen

Er filen ændret på disken, siden den blev åbnet, afvises gemningen, og Restorm beder dig om at Genindlæse eller Beholde din version.

Hvorfor diffene er læsbare

To egenskaber ved formatet, som er beskrevet i Projekter og .restorm-filer: en kanonisk nøglerækkefølge og id’er, der udledes stabilt.

Følgen: at åbne og gemme igen uden at ændre noget giver ikke noget diff, og to personer, der tilføjer den samme anmodning det samme sted, producerer enheder, som fletningen kan parre.

Historik

Git ▸ Historik åbner en visning med to ruder: listen over commits med en grenrende og detaljerne til højre. En commits kontekstmenu lader dig hente den version.

Via MCP

Fire værktøjer, i Pro-udgaven: git_commit_push (trin 1 af 2 — returnerer et gennemgangstoken, titlen, brødteksten og diffet pr. enhed uden at skrive noget), git_confirm_push (trin 2 af 2 — afvises, hvis projektet er ændret siden gennemgangen), git_pull og git_resolve_conflicts.

Opdelingen i to trin er bevidst: en agent kan ikke pushe, uden at et diff først er blevet præsenteret.