Branch workspaces de Fabric: ¿listos para Git en equipo?

Durante años, la configuración por defecto de un equipo en Fabric fue un único workspace de desarrollo conectado a Git que todo el mundo editaba. Funciona hasta que dos personas tocan el mismo modelo semántico la misma semana. Entonces la pregunta "¿quién ha cambiado esto?" llega a Git como un commit enorme con el trabajo de otra persona metido dentro.

Los branch workspaces venían a resolver eso, y las partes importantes pasaron a GA en septiembre de 2026. Recorrí el ciclo completo en una capacidad de prueba con datos sintéticos: branch out con solo algunos elementos, editar, comparar, hacer commit, fusionar y actualizar el workspace compartido con un conflicto real esperando. Este post responde a una pregunta: ¿está listo para ser la opción por defecto del equipo?

Figura 1. El workspace compartido solo cambia en el paso 4. Cada paso tiene un control que puedes comprobar.

Qué ha cambiado

La opción antigua era mala en los dos sentidos. Un workspace de desarrollo compartido significaba un desorden compartido. Un branch out completo copiaba todos los elementos a un workspace nuevo, algo lento y caro en cuanto un workspace tiene decenas de elementos.

Ahora hay tres cosas distintas:

• Branching selectivo. En el diálogo de branch out puedes elegir "Select items individually", y "Select related items" añade aquello de lo que depende tu selección. Más adelante puedes usar "Add more items" si el cambio crece.
• Compare and commit. Antes de hacer commit o update, obtienes un diff de los archivos del elemento, en paralelo o en línea, y la vista de conflictos permite comparar a tres bandas.
• Una fecha firme para los permisos. Learn dice ahora que a partir del 28 de febrero de 2027 los usuarios sin permiso de lectura y escritura sobre los elementos del workspace no podrán usar la integración con Git. Learn lo vincula a los elementos con etiquetas de confidencialidad y directivas de protección. Hasta el 26 de octubre de 2026, Learn decía el 1 de diciembre de 2026. Si en tu equipo hay personas con acceso de solo lectura a algunos elementos de un workspace de desarrollo, planifícalo ya.

La parte selectiva tiene demanda real. Un hilo de la Fabric Community pregunta justo cómo hacer branch out con solo algunos elementos.

Qué se ha publicado: el ciclo que probé

El workspace de prueba tenía cinco elementos: un lakehouse vacío, un notebook vacío, un modelo semántico pequeño en TMDL con cinco filas sintéticas y una medida, un informe en PBIR con una tarjeta y una variable library. Todo estaba con commit en una rama de desarrollo desde el principio. Esa base importa, como verás.

Recortar. Elegí solo el informe y pulsé Select related items. El modelo semántico se añadió solo, porque el informe está enlazado a él.

Figura 2. Elige el elemento que vas a cambiar y deja que Select related items añada sus dependencias. Los nombres están difuminados.

El workspace nuevo tenía dos elementos. Cuando el cambio se extendió a la variable library, Add more items y un update la trajeron, con lo que quedaron tres elementos en total.

Figura 3. Dos elementos en lugar de cinco. El icono junto al nombre de la rama en la barra de estado indica una rama selectiva.

Hay un detalle de los informes que conviene conocer. El definition.pbir con commit apuntaba al modelo por ruta. Cuando leí la definición del mismo informe con la API Get Item Definition, apuntaba por conexión, con el ID del modelo dentro. Ese ID nunca llegó a Git, que es lo que quieres, así que el informe del branch workspace se enlaza a la copia del modelo de su propio workspace. La página de Learn sobre la carpeta de informes PBIR dice que la integración con Git siempre exporta una referencia byPath cuando el informe y el modelo comparten workspace.

Comparar. Cambié la cadena de formato de una medida, añadí una segunda medida, cambié el título de la tarjeta y edité dos valores en la variable library. La vista en paralelo mostró el cambio de TMDL línea por línea. Es lo mejor de esta versión. Ves exactamente lo que estás a punto de meter en Git.

Figura 4. Lee esto antes de cada commit. El diff es por archivo, así que ves qué parte del elemento ha cambiado.

Una pega: el commit del cambio de la medida también se llevó el cambio del título de la tarjeta, porque el informe también tenía cambios y estaba marcado. Lee la lista completa de elementos antes de hacer commit, no solo el elemento por el que venías.

Fusionar. El pull request pasó por el proveedor de Git como siempre. Fabric no interviene, y de eso se trata: la revisión, las políticas de rama y las aprobaciones siguen donde ya estaban.

Asentar. Aquí es donde pasó lo interesante. Más abajo lo cuento.

Figura 5. Monta el proceso sobre la columna de la izquierda. Prueba la columna de la derecha en piloto, pero no la conviertas en un paso del que dependa la gente.

Qué no está listo todavía

El commit a nivel de archivo está en Preview y es limitado. Te permite hacer commit de algunos archivos de un elemento y dejar el resto. Solo funciona con algunos tipos de elemento: Warehouse, SQL database, notebooks, Environment, Spark job definitions, pipelines, Dataflow Gen2 y Variable Library. Los modelos semánticos y los informes no están en la lista, y son justo los elementos por los que más se pelean los equipos.

Lo probé con la variable library: hice commit del archivo de variables y dejé sin commit un archivo de conjunto de valores. Funcionó, y el conjunto de valores se quedó como Modified en el workspace. El aviso es honesto:

Figura 6. Fabric te dice que un commit parcial puede dejar una definición no válida en Git. Créetelo.

El diálogo, titulado "Commit partial selection? (preview)", dice: "Committing part of an item's changes can leave its definition incomplete or invalid in Git. You may need to fix it manually before importing the item again." Resérvalo para los casos en que sepas que dividir los archivos es seguro.

Algunas piezas de administración están en Preview. Los perfiles de administración de branch workspaces, el ajuste del workspace que permite a los Contributors cambiar la rama de Git, la Workspace Relation API y los deployment plans están todos en Preview. La Workspace Relation API devolvió los tipos de relación correctos en mi prueba (Branch en el origen, Base en el branch workspace), así que la automatización es posible, pero todavía no es algo para meter en un pipeline de producción.

Lee con atención las etiquetas de Preview. La página de Learn sobre branched workspaces muestra "Select items individually (Preview)" solo en su sección de deployment plans, y los deployment plans están en Preview. El branching selectivo en sí es GA según What's new. La página también dice que la barra de estado "says selective branch"; en mi prueba era un icono junto al nombre de la rama.

Cuando el update se encuentra con una edición local

La prueba de conflicto era sencilla. El pull request cambiaba el formato de la medida de un patrón de decimales a otro. Mientras tanto, alguien había editado la misma cadena de formato en el workspace compartido y no había hecho commit. Tres versiones de una misma línea.

La pestaña Updates marcó el conflicto. La vista de comparación tiene tres modos: "Last sync vs. remote", "Workspace vs Remote" y "Last sync vs. workspace". El diálogo donde eliges se titula "Merge and update content to resolve conflicts". Los modos son útiles. Last sync vs. workspace muestra lo que alguien hizo en local, y esa es la edición que estás a punto de perder.

Figura 7. En pantalla: Last sync vs. remote. Cambia a Last sync vs. workspace antes de elegir; muestra la edición local que estás a punto de perder.

Elegí Accept incoming changes y después Merge And Update. El workspace terminó con el formato fusionado. La edición local había desaparecido. Learn lo dice tal cual: los cambios del workspace se pierden. Es el comportamiento correcto para un equipo que trata el pull request como la verdad. También es una forma silenciosa de tirar a la basura la tarde de alguien que editó el workspace compartido sin avisar a nadie.

Figura 8. Accept incoming significa que gana el PR y la edición local desaparece. Keep current content significa que aún debes un commit.

Luego vino la sorpresa. Después del update, el informe, que no estaba en el conflicto, aparecía sin commit con un cambio. Después de un update, el workspace debería coincidir con la rama, así que todos los elementos deberían estar en Synced. El cambio parece ser la descripción del elemento: estaba vacía en el workspace compartido mientras que la copia en Git todavía la tenía, y Learn indica que los cambios de metadatos participan en la sincronización con Git. Lo vi una vez, no lo encontré documentado (comprobado el 30 de octubre de 2026) y no lo voy a llamar bug. Lo llamo un motivo para añadir un paso: mira el estado de Git después de cada update y no dejes un workspace que todavía muestre cambios.

Cuándo decir que sí

Haz que los branch workspaces sean la opción por defecto cuando:

• Más de una persona cambia el mismo workspace de desarrollo en el mismo sprint.
• Tu proveedor de Git ya se encarga de la revisión, de modo que el pull request puede ser el único camino de vuelta para los cambios.
• Tus elementos están en la lista de elementos soportados por la integración con Git y los informes usan PBIR para que los diffs se puedan leer.
• Puedes hacer commit del workspace compartido antes de que la gente haga branch out. Si el workspace compartido suele tener trabajo sin commit, arregla eso primero.

Espera, o empieza en pequeño, cuando:

• Tu proceso depende de commits parciales de modelos semánticos o informes. No está soportado.
• Necesitas como control los perfiles de administración o el ajuste del workspace para que los Contributors cambien de rama. Están en Preview.
• A algunas personas del workspace de desarrollo les falta acceso de escritura a algunos elementos, por ejemplo por la protección de etiquetas de confidencialidad. A partir del 28 de febrero de 2027 no podrán usar la integración con Git, así que resuelve primero los accesos.

Mi respuesta al título: sí para el ciclo principal, con dos reglas por escrito. Nadie edita directamente el workspace compartido mientras hay una rama abierta, y cada update termina con una comprobación de estado.

Errores comunes

• Hacer branch out desde trabajo sin commit. Branch out usa el último commit del workspace de origen. Lo que no tiene commit no está en tu rama.
• Hacer branch out a un workspace existente. Puede borrar elementos sin commit que ya estén allí. Usa un workspace nuevo.
• Cambiar de rama en un workspace selectivo. La selección se reinicia y te llegan todos los elementos. Crea mejor un branch workspace nuevo.
• Esperar que los ajustes te sigan. Los ajustes del workspace original no se copian. Desconectarlo elimina la relación.
• Esperar que Update respete la selección. Update en el workspace compartido trae la rama completa.
• Pulsar Accept incoming sin mirar. Comprueba primero Last sync vs. workspace. La edición local no tiene otra forma de volver.
• Commits parciales en elementos que necesitan todos sus archivos. Fabric te avisa de que la definición puede acabar siendo no válida.
• Fiarte de la comparación para cualquier archivo. La comparación no muestra el contenido de archivos binarios ni de archivos de más de 1 MB.

Úsalo tal cual o adáptalo

Úsalo tal cual si tu equipo ya trabaja con pull requests:

1. Haz commit del workspace de desarrollo compartido. El estado debería ser Synced antes de que nadie haga branch out.
2. Haz branch out a un workspace nuevo por cada cambio. Elige los elementos y pulsa Select related items.
3. Lee la vista de comparación antes de cada commit. Haz commit de elementos completos.
4. Fusiona solo mediante pull request.
5. En el workspace compartido, revisa la pestaña Updates, resuelve los conflictos con Last sync vs. workspace abierto y comprueba el estado de Git. No termines hasta que esté en Synced.
6. Borra el branch workspace cuando se haya fusionado el pull request.

Adáptalo si:

• Tienes muchos notebooks o pipelines y quieres el commit a nivel de archivo. Pruébalo en piloto con un tipo de elemento y añade una comprobación de que el elemento se sigue pudiendo importar desde Git.
• Quieres automatizar la creación de branch workspaces. La Workspace Relation API funciona, pero está en Preview, así que mantén una alternativa manual.
• Tu capacidad es compartida y pequeña. Un branch workspace también consume capacidad, así que mantén la selección ajustada.

Pruébalo tú

La demo completa, con los pasos, las observaciones y las evidencias, está en tech-demos/fabric-branch-workspaces. Se ejecuta en una capacidad de prueba con datos sintéticos, y los tiempos que incluye son ejecuciones únicas, no benchmarks.

Relacionado

• Fabric CI/CD: ¿cómo limitas el blast radius entre workspaces de desarrollo? (lo que toca un despliegue frente a lo que cambió Git)
• Fabric CI/CD: ¿fusionar toda la escalera o hacer cherry-pick de lo que está listo? (hacer avanzar un cambio cuando la rama contiene varios)
• Variable Library: ¿cómo cambias los conjuntos de valores activos de dev a prod? (cómo se comportan los conjuntos de valores entre etapas, algo que importa en cuanto los branch workspaces los editan)
• Nombres de workspaces: ¿sale más barato renombrar una vez que traducir prefijos para siempre? (los branch workspaces se multiplican rápido, así que ponles nombre a conciencia)