Cómo conectar un workspace de Microsoft Fabric a Git

Conectar un workspace de Microsoft Fabric a Git te da control de versiones de verdad: cada informe, notebook o pipeline pasa a tener historial, revisión y la posibilidad de volver atrás cuando algo sale mal. Es también la base para que varias personas trabajen en el mismo workspace sin pisarse el trabajo.

Requisitos previos

• Un workspace de Microsoft Fabric asignado a una capacidad Fabric (o Premium) y el rol de Admin en ese workspace.
• Un repositorio en Azure DevOps (Azure Repos) o GitHub. En el caso de Azure DevOps, la cuenta debe pertenecer al mismo tenant de Microsoft Entra ID.
• Una rama de destino (por ejemplo main) y, opcionalmente, una carpeta dentro del repositorio.
• La integración con Git habilitada en la configuración del tenant por el administrador de Fabric.

Paso 1: Preparar el repositorio

Crea (o elige) un repositorio y asegúrate de que tiene al menos una rama inicializada: un repositorio sin ningún commit no se puede conectar. Reserva una carpeta solo para Fabric, por ejemplo /fabric. Si el repositorio también guarda código de otros equipos, los elementos del workspace quedan ordenados.

Consejo: usa una carpeta por entorno (por ejemplo /fabric/dev) si más adelante quieres conectar workspaces distintos al mismo repositorio.

Paso 2: Conectar el workspace a Git

En el workspace, abre Workspace settings y ve a la pestaña Git integration. Elige el proveedor (Azure DevOps o GitHub), autentícate y rellena los campos: organización, proyecto, repositorio, rama y carpeta. Después haz clic en Connect and sync.

En la primera conexión, Fabric compara lo que hay en el workspace con lo que hay en la carpeta del repositorio. Si uno de los lados está vacío, la sincronización es inmediata; si ambos tienen contenido, tendrás que elegir cuál prevalece.

Paso 3: Hacer el primer commit

Una vez conectado, aparece arriba en el workspace el botón Source control. Ábrelo: los elementos compatibles (informes, semantic models, notebooks, pipelines, lakehouses y otros) aparecen como Uncommitted. Selecciona los que quieres versionar, escribe un mensaje claro y haz clic en Commit.

En el repositorio, cada elemento pasa a ser una carpeta con su definición guardada en texto:

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

El fichero .platform guarda los metadatos del elemento (tipo, nombre e identificador lógico). No lo edites a mano.

Paso 4: Trabajar en una rama separada

Para desarrollar sin tocar el workspace principal, usa Branch out to another workspace en el panel de Source control. Fabric crea una rama nueva a partir de la actual y un workspace nuevo ya conectado a ella. Haz los cambios, haz commit y después abre un pull request en Azure DevOps o GitHub, igual que harías con código normal.

Paso 5: Actualizar desde Git y resolver conflictos

Cuando alguien hace merge en tu rama, el panel de Source control muestra los elementos como Update required. Haz clic en Update all para traer los cambios al workspace.

Si el mismo elemento se modificó en los dos lados, Fabric marca un conflicto y te pide elegir qué versión conservar: la del workspace o la de Git. Este es el error más común al empezar, y se evita con una regla simple: actualiza antes de empezar a trabajar y haz commit en pasos pequeños.

Paso 6 (opcional): Automatizar con la API REST de Fabric

Si quieres integrar el commit en un pipeline de CI/CD, Fabric expone endpoints de Git. Un ejemplo mínimo para enviar todo lo pendiente:

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

{
  "mode": "All",
  "comment": "Commit automático desde el pipeline"
}

Existen endpoints equivalentes para updateFromGit y para consultar el status, útiles para validar si un entorno está sincronizado antes de promover cambios.

Verificar el resultado

Comprueba tres cosas. Primero, en el repositorio: la carpeta configurada tiene una subcarpeta por elemento y un commit con tu mensaje. Segundo, en el workspace: el panel de Source control muestra Synced y ningún cambio pendiente. Tercero, haz una prueba real: cambia el título de un informe, confirma que aparece como Modified, haz commit y mira el diff en Git.

Conclusión

Con el workspace conectado a Git tienes historial, revisión por pull request y un camino natural hacia CI/CD con deployment pipelines. El siguiente paso es crear workspaces separados para dev, test y producción, cada uno conectado a su rama. Antes de seguir, una pregunta para pensar: si hoy se borrara un informe por error, ¿cuánto tardarías en recuperarlo?