Git integrado

Um projeto Restorm foi feito para viver num repositório git. A integração vai mais longe do que um simples git commit: compreende o formato e sabe resolver um conflito ao nível das entidades de negócio, não das linhas de YAML.

Primeiros passos

Não há nada a configurar. Assim que o ficheiro .restorm aberto se encontrar num repositório git, as superfícies git ativam-se.

O Restorm utiliza o seu git local: não há credenciais a introduzir nem gestão de tokens na aplicação. A regra é simples — se git push funciona no seu terminal, funciona no Restorm. O git é lançado com as solicitações interativas desativadas: um repositório que pedisse uma palavra-passe falha imediatamente com a mensagem do próprio git, em vez de bloquear a interface.

A célula GIT da barra de estado

Dois botões, Enviar e Obter, cada um com uma marca (um ponto, nunca um número) quando há algo para enviar ou uma versão mais recente para obter.

O menu Git da barra de título oferece as mesmas ações, mais Atualizar, Repor para a versão do servidor e Histórico.

A célula GIT da barra de estado: Atualizar, Enviar e Obter, com uma marca em cada um destes dois últimos, e depois Histórico. A dica de contexto “Enviar para o repositório” está aberta.

Enviar

A janela modal de envio mostra uma mensagem de commit já redigida, gerada de forma determinista a partir do diff estrutural — sem qualquer modelo de linguagem. Uma linha por entidade modificada (pedido, cenário, pasta, pasta de variáveis), nunca uma linha por campo.

Um seletor de idioma da mensagem, independente do idioma da interface, com um interruptor para o tornar a predefinição.
Um título editável, com um contador indicativo nos 72 caracteres.
Um corpo com várias linhas.

Confirmar encadeia: guardar, git add, commit, push.

Obter

O Restorm guarda primeiro, e depois obtém e funde as alterações.

Fusão limpa: a árvore e os separadores abertos atualizam-se no lugar.

Conflito: abre-se uma vista de resolução com quatro painéis.

A vista de resolução de conflitos com quatro painéis: a lista de conflitos à esquerda, a sua versão, a versão do servidor — os URL que divergem estão enquadrados a vermelho — e o painel “Resolvido” preenchido depois de ter mantido a sua versão.

Painel	Conteúdo
Lista de conflitos	As entidades em conflito
A sua versão	Apenas de leitura
A versão deles	Apenas de leitura
Resolvido	Editável — é isto que será escrito

O ponto importante: cada painel mostra a entidade no seu verdadeiro editor — um pedido HTTP no editor HTTP, um cenário no editor de cenários. Não está a resolver marcadores <<<<<<< em YAML, está a comparar dois pedidos.

Há um botão “utilizar esta versão” por lado, e os campos que divergem são realçados a vermelho — quando apenas um campo difere, o painel abre-se diretamente no separador em questão.

A documentação de API de uma pasta de variáveis resolve-se automaticamente (prevalece a versão mais recente).

Cancelar executa um git merge --abort. Se fechar a aplicação em plena resolução, no arranque seguinte será proposto abandonar a fusão.

Verificação em fundo (semi-pull)

O Restorm verifica periodicamente se existe uma versão mais recente — sem nunca fundir por si só. Três desencadeadores: uma modificação observada em .git, a abertura de um ficheiro e um temporizador cuja frequência se ajusta em Definições ▸ Git (Off, 15 min, 30 min, 1 h, 4 h, 12 h, 24 h).

Uma notificação “Atualização disponível” propõe então Pull now.

Modificação externa do ficheiro

Se o ficheiro mudou no disco desde a sua abertura, a gravação é recusada e o Restorm pede-lhe para Recarregar ou para Manter a sua versão.

Por que razão os diffs são legíveis

Duas propriedades do formato, descritas em Projetos e ficheiros .restorm: uma ordem de chaves canónica e identificadores derivados de forma estável.

Consequência: abrir e voltar a guardar sem alterar nada não produz nenhum diff, e duas pessoas que adicionam o mesmo pedido no mesmo lugar produzem entidades que a fusão sabe emparelhar.

Histórico

Git ▸ Histórico abre uma vista com dois painéis: a lista de commits com uma calha de ramos, e o detalhe à direita. O menu de contexto de um commit permite recuperar essa versão.

Por MCP

Quatro ferramentas, na edição Pro: git_commit_push (passo 1 de 2 — devolve um token de revisão, o título, o corpo e o diff por entidade, sem escrever nada), git_confirm_push (passo 2 de 2 — recusado se o projeto mudou desde a revisão), git_pull e git_resolve_conflicts.

A divisão em dois passos é deliberada: um agente não pode enviar sem que um diff tenha sido apresentado primeiro.