Como ligar um workspace do Microsoft Fabric ao Git

João Barros 12 de July de 2026 5 min de leitura

Ligar um workspace do Microsoft Fabric ao Git dá-lhe controlo de versões a sério: cada relatório, notebook ou pipeline passa a ter histórico, revisão e a possibilidade de voltar atrás quando algo corre mal. É também a base para várias pessoas trabalharem no mesmo workspace sem apagarem o trabalho umas das outras.

Pré-requisitos

Um workspace do Microsoft Fabric atribuído a uma capacidade Fabric (ou Premium) e o papel de Admin nesse workspace.
Um repositório em Azure DevOps (Azure Repos) ou GitHub. No caso do Azure DevOps, a conta tem de pertencer ao mesmo tenant do Microsoft Entra ID.
Uma branch de destino (por exemplo main) e, opcionalmente, uma pasta dentro do repositório.
A integração com Git ativada nas definições de tenant pelo administrador do Fabric.

Passo 1: Preparar o repositório

Crie (ou escolha) um repositório e garanta que ele tem pelo menos uma branch inicializada — um repositório sem qualquer commit não pode ser ligado. Reserve uma pasta só para o Fabric, por exemplo /fabric: se o repositório também guardar código de outras equipas, os itens do workspace ficam bem arrumados.

Dica: use uma pasta por ambiente (por exemplo /fabric/dev) se pretender mais tarde ligar workspaces diferentes ao mesmo repositório.

Passo 2: Ligar o workspace ao Git

No workspace, abra Workspace settings e escolha o separador Git integration. Selecione o fornecedor (Azure DevOps ou GitHub), autentique-se e preencha os campos: organização, projeto, repositório, branch e pasta. Depois clique em Connect and sync.

Sendo a primeira ligação, o Fabric compara o que existe no workspace com o que existe na pasta do repositório. Se um dos lados estiver vazio, a sincronização é imediata; se ambos tiverem conteúdo, terá de escolher qual prevalece.

Passo 3: Fazer o primeiro commit

Depois de ligado, aparece no topo do workspace o botão Source control. Abra-o: os itens suportados (relatórios, semantic models, notebooks, pipelines, lakehouses, entre outros) surgem com o estado Uncommitted. Selecione os que quer versionar, escreva uma mensagem clara e clique em Commit.

No repositório, cada item passa a ser uma pasta com a sua definição guardada em texto:

/fabric
  /Vendas.Report
      .platform
      definition.pbir
  /Vendas.SemanticModel
      .platform
      definition/
  /Ingestao.Notebook
      .platform
      notebook-content.py

O ficheiro .platform guarda os metadados do item (tipo, nome e identificador lógico). Não o edite à mão.

Passo 4: Trabalhar numa branch separada

Para desenvolver sem tocar no workspace principal, use Branch out to another workspace no painel de Source control. O Fabric cria uma branch nova a partir da atual e um workspace novo já ligado a essa branch. Faça as alterações, faça commit e depois abra um pull request no Azure DevOps ou no GitHub, tal como faria com código normal.

Passo 5: Atualizar do Git e resolver conflitos

Quando alguém faz merge para a sua branch, o painel de Source control mostra os itens com o estado Update required. Clique em Update all para trazer as alterações para o workspace.

Se o mesmo item foi alterado dos dois lados, o Fabric assinala um conflito e pede-lhe que escolha a versão a manter: a do workspace ou a do Git. Este é o erro mais comum de quem está a começar, e evita-se com uma regra simples: fazer update antes de começar a trabalhar e commit em passos pequenos.

Passo 6 (opcional): Automatizar com a API REST do Fabric

Se quiser integrar o commit numa pipeline de CI/CD, o Fabric expõe endpoints de Git. Um exemplo mínimo para enviar tudo o que está por confirmar:

POST https://api.fabric.microsoft.com/v1/workspaces/{workspaceId}/git/commitToGit
Authorization: Bearer <token>
Content-Type: application/json

{
  "mode": "All",
  "comment": "Commit automático a partir da pipeline"
}

Existem endpoints equivalentes para updateFromGit e para consultar o status, úteis para validar se um ambiente está sincronizado antes de promover alterações.

Verificar o resultado

Confirme três coisas. Primeiro, no repositório: a pasta configurada tem uma subpasta por item e um commit com a sua mensagem. Segundo, no workspace: o painel de Source control mostra Synced e nenhuma alteração pendente. Terceiro, faça um teste real: mude o título de um relatório, confirme que ele aparece como Modified, faça commit e veja o diff no Git.

Conclusão

Com o workspace ligado ao Git, tem histórico, revisão por pull request e um caminho natural para CI/CD com deployment pipelines. O passo seguinte é criar workspaces separados para dev, teste e produção, cada um ligado à sua branch. Antes de avançar, fica a pergunta: se um relatório fosse apagado por engano hoje, quanto tempo demoraria a recuperá-lo?