Fabric Branch Workspaces: Bereit für Git im Team?

Jahrelang war das Standard-Setup für Fabric-Teams ein mit Git verbundener Dev-Workspace, den alle bearbeitet haben. Das funktioniert, bis zwei Leute in derselben Woche dasselbe semantische Modell anfassen. Dann landet die Frage "Wer hat das geändert?" in Git als ein großer Commit, in den die Arbeit von jemand anderem mit hineingefaltet ist.

Branch Workspaces sollten das lösen, und die Teile, auf die es ankommt, sind im September 2026 GA geworden. Ich habe den kompletten Ablauf auf einer Trial-Kapazität mit synthetischen Daten durchgespielt: Branch out mit nur einigen Items, bearbeiten, vergleichen, committen, mergen und den gemeinsamen Workspace aktualisieren, während ein echter Konflikt wartet. Dieser Beitrag beantwortet eine Frage: Ist es reif, der Standard im Team zu werden?

Abbildung 1. Der gemeinsame Workspace ändert sich erst in Schritt 4. Jeder Schritt hat eine Schranke, die du prüfen kannst.

Was sich geändert hat

Die alte Wahl war in beide Richtungen schlecht. Ein gemeinsamer Dev-Workspace hieß gemeinsames Chaos. Ein vollständiges Branch out kopierte jedes Item in einen neuen Workspace, was langsam und teuer ist, sobald ein Workspace Dutzende Items hat.

Drei Dinge sind jetzt anders:

• Selektives Branching. Im Dialog für Branch out kannst du "Select items individually" wählen, und "Select related items" fügt hinzu, wovon deine Auswahl abhängt. Später kannst du mit "Add more items" nachlegen, wenn die Änderung wächst.
• Compare and Commit. Vor einem Commit oder Update bekommst du einen Diff der Item-Dateien, nebeneinander oder inline, und die Konfliktansicht erlaubt einen Dreiwegevergleich.
• Ein festes Datum für Berechtigungen. Learn sagt jetzt, dass Nutzer ohne Lese- und Schreibberechtigung auf Workspace-Items ab dem 28. Februar 2027 die Git-Integration nicht mehr nutzen können. Learn bezieht das auf Items mit Vertraulichkeitsbezeichnungen und Schutzrichtlinien. Bis zum 26. Oktober 2026 stand bei Learn der 1. Dezember 2026. Wenn in deinem Team Leute auf manche Items in einem Dev-Workspace nur Lesezugriff haben, plane das jetzt ein.

Für den selektiven Teil gibt es echten Bedarf. Ein Thread in der Fabric Community fragt genau danach, wie man ein Branch out mit nur einigen Items macht.

Was ausgeliefert wurde: der Ablauf, den ich getestet habe

Der Test-Workspace hatte fünf Items: ein leeres Lakehouse, ein leeres Notebook, ein kleines semantisches Modell in TMDL mit fünf synthetischen Zeilen und einem Measure, einen Bericht in PBIR mit einer Karte und eine Variable Library. Alles war zuerst in einen Dev-Branch committet. Diese Basis ist wichtig, wie du gleich sehen wirst.

Zuschneiden. Ich habe nur den Bericht gewählt und Select related items gedrückt. Das semantische Modell kam automatisch dazu, weil der Bericht daran gebunden ist.

Abbildung 2. Wähle das Item, das du änderst, und lass Select related items seine Abhängigkeiten hinzufügen. Namen sind unkenntlich gemacht.

Der neue Workspace enthielt zwei Items. Als die Änderung auf die Variable Library übergriff, holten Add more items und ein Update sie dazu, insgesamt also drei Items.

Abbildung 3. Zwei Items statt fünf. Das Symbol neben dem Branch-Namen in der Statusleiste kennzeichnet einen selektiven Branch.

Ein Detail zu Berichten lohnt sich. Die committete definition.pbir verwies per Pfad auf das Modell. Als ich die Definition desselben Berichts über die Get Item Definition API gelesen habe, verwies sie per Verbindung, mit der Modell-ID darin. Diese ID ist nie in Git gelandet, und genau das willst du: So bindet sich der Bericht im Branch Workspace an die Modellkopie im eigenen Workspace. Die Learn-Seite zum PBIR-Berichtsordner sagt, dass die Git-Integration immer eine byPath-Referenz exportiert, wenn Bericht und Modell im selben Workspace liegen.

Vergleichen. Ich habe den Formatstring eines Measures geändert, ein zweites Measure hinzugefügt, den Titel der Karte geändert und zwei Werte in der Variable Library bearbeitet. Die Ansicht nebeneinander zeigte die TMDL-Änderung Zeile für Zeile. Das ist der beste Teil des Releases. Du siehst genau, was du gleich in Git schreibst.

Abbildung 4. Lies das vor jedem Commit. Der Diff ist pro Datei, du siehst also, welcher Teil des Items sich geändert hat.

Ein Haken: Der Commit für die Measure-Änderung hat auch die Änderung am Kartentitel mitgenommen, weil der Bericht ebenfalls Änderungen hatte und angehakt war. Lies vor dem Commit die ganze Item-Liste, nicht nur das Item, wegen dem du gekommen bist.

Mergen. Der Pull Request lief wie gewohnt über den Git-Provider. Fabric ist daran nicht beteiligt, und genau darum geht es: Review, Branch Policies und Genehmigungen bleiben, wo sie schon sind.

Abschließen. Hier wurde es interessant. Mehr dazu weiter unten.

Abbildung 5. Bau den Prozess auf der linken Spalte auf. Pilotiere die rechte Spalte, aber mach sie nicht zu einem Schritt, von dem Leute abhängen.

Was noch nicht reif ist

File Level Commit ist Preview, und eng. Damit committest du einige Dateien eines Items und lässt den Rest liegen. Das funktioniert nur für einige Item-Typen: Warehouse, SQL database, Notebooks, Environment, Spark Job Definitions, Pipelines, Dataflow Gen2 und Variable Library. Semantische Modelle und Berichte stehen nicht auf der Liste, und genau um diese Items streiten Teams am meisten.

Ich habe es an der Variable Library ausprobiert: Ich habe die Datei mit den Variablen committet und eine Datei mit einem Wertesatz nicht committet. Das hat funktioniert, und der Wertesatz blieb im Workspace als Modified. Die Warnung ist ehrlich:

Abbildung 6. Fabric sagt dir, dass ein Teil-Commit eine ungültige Definition in Git hinterlassen kann. Glaub es.

Der Dialog mit dem Titel "Commit partial selection? (preview)" sagt: "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." Heb dir das für Fälle auf, in denen du weißt, dass die Aufteilung der Dateien sicher ist.

Einige Admin-Funktionen sind Preview. Admin-Profile für Branch Workspaces, die Workspace-Einstellung, mit der Contributors den Git-Branch wechseln dürfen, die Workspace Relation API und Deployment Plans sind alle Preview. Die Workspace Relation API hat in meinem Test die richtigen Beziehungstypen zurückgegeben (Branch an der Quelle, Base am Branch Workspace). Automatisierung ist also möglich, aber noch nichts für eine produktive Pipeline.

Lies die Preview-Kennzeichnungen genau. Die Learn-Seite zu Branched Workspaces zeigt "Select items individually (Preview)" nur im Abschnitt zu Deployment Plans, und Deployment Plans sind Preview. Selektives Branching selbst ist laut What's new GA. Die Seite sagt außerdem, die Statusleiste "says selective branch". In meinem Lauf war es ein Symbol neben dem Branch-Namen.

Wenn das Update auf einen lokalen Edit trifft

Der Konflikttest war einfach. Der Pull Request änderte das Format des Measures von einem Muster mit Nachkommastellen auf ein anderes. In der Zwischenzeit hatte jemand denselben Formatstring im gemeinsamen Workspace bearbeitet und nicht committet. Drei Versionen einer Zeile.

Der Tab Updates hat den Konflikt markiert. Die Vergleichsansicht hat drei Modi: "Last sync vs. remote", "Workspace vs Remote" und "Last sync vs. workspace". Der Dialog, in dem du wählst, heißt "Merge and update content to resolve conflicts". Die Modi sind nützlich. Last sync vs. workspace zeigt, was jemand lokal gemacht hat, und das ist der Edit, den du gleich verlierst.

Abbildung 7. Zu sehen: Last sync vs. remote. Wechsle vor deiner Wahl zu Last sync vs. workspace. Dort siehst du den lokalen Edit, den du gleich verlierst.

Ich habe Accept incoming changes gewählt und dann Merge And Update. Der Workspace hatte am Ende das gemergte Format. Der lokale Edit war weg. Learn sagt genau das: Die Änderungen im Workspace gehen verloren. Das ist das richtige Verhalten für ein Team, das den Pull Request als Wahrheit behandelt. Es ist auch ein leiser Weg, jemandem einen Nachmittag Arbeit zu vernichten, wenn er den gemeinsamen Workspace bearbeitet und niemandem Bescheid gesagt hat.

Abbildung 8. Accept incoming heißt, der PR gewinnt und der lokale Edit ist weg. Keep current content heißt, du schuldest noch einen Commit.

Dann die Überraschung. Nach dem Update zeigte der Bericht, der nicht im Konflikt war, eine nicht committete Änderung. Nach einem Update sollte der Workspace dem Branch entsprechen, also sollte jedes Item Synced sein. Die Änderung scheint die Item-Beschreibung zu sein: Sie war im gemeinsamen Workspace leer, während die Kopie in Git sie noch hatte, und Learn weist darauf hin, dass Metadatenänderungen an der Git-Synchronisierung teilnehmen. Ich habe das einmal gesehen, konnte es nicht dokumentiert finden (geprüft am 30. Oktober 2026) und nenne es keinen Bug. Ich nenne es einen Grund für einen zusätzlichen Schritt: Schau nach jedem Update auf den Git-Status und lass keinen Workspace liegen, der noch Änderungen zeigt.

Wann du Ja sagen solltest

Mach Branch Workspaces zum Standard, wenn:

• mehr als eine Person im selben Sprint denselben Dev-Workspace ändert.
• dein Git-Provider das Review schon übernimmt, sodass der Pull Request der einzige Weg zurück für Änderungen sein kann.
• deine Items auf der Liste der unterstützten Items für die Git-Integration stehen und Berichte PBIR verwenden, damit die Diffs lesbar sind.
• du den gemeinsamen Workspace committen kannst, bevor Leute ein Branch out machen. Wenn der gemeinsame Workspace oft nicht committete Arbeit enthält, behebe das zuerst.

Warte, oder halte es klein, wenn:

• dein Prozess von Teil-Commits semantischer Modelle oder Berichte abhängt. Das wird nicht unterstützt.
• du Admin-Profile oder die Workspace-Einstellung zum Branch-Wechsel durch Contributors als Kontrolle brauchst. Die sind Preview.
• Leuten im Dev-Workspace Schreibzugriff auf einige Items fehlt, zum Beispiel wegen Schutz durch Vertraulichkeitsbezeichnungen. Ab dem 28. Februar 2027 können sie die Git-Integration nicht nutzen, also kläre die Zugriffe zuerst.

Meine Antwort auf den Titel: Ja für den Kernablauf, mit zwei schriftlich festgehaltenen Regeln. Niemand bearbeitet den gemeinsamen Workspace direkt, solange ein Branch offen ist, und jedes Update endet mit einer Statusprüfung.

Häufige Fehler

• Branch out aus nicht committeter Arbeit. Branch out verwendet den letzten Commit des Quell-Workspace. Was nicht committet ist, ist nicht in deinem Branch.
• Branch out in einen bestehenden Workspace. Das kann dort bereits vorhandene, nicht committete Items löschen. Nimm einen neuen Workspace.
• Branch-Wechsel in einem selektiven Workspace. Die Auswahl wird zurückgesetzt, und du bekommst jedes Item. Leg stattdessen einen neuen Branch Workspace an.
• Erwarten, dass Einstellungen mitkommen. Einstellungen aus dem ursprünglichen Workspace werden nicht kopiert. Wenn du ihn trennst, wird die Beziehung entfernt.
• Erwarten, dass Update die Auswahl respektiert. Update im gemeinsamen Workspace übernimmt den ganzen Branch.
• Accept incoming klicken, ohne hinzuschauen. Prüf zuerst Last sync vs. workspace. Der lokale Edit hat keinen anderen Weg zurück.
• Teil-Commits bei Items, die alle ihre Dateien brauchen. Fabric warnt dich, dass die Definition ungültig werden kann.
• Dem Vergleich bei jeder Datei vertrauen. Der Vergleich zeigt keine Inhalte von Binärdateien oder Dateien über 1 MB.

So übernehmen oder anpassen

So übernehmen, wenn dein Team schon mit Pull Requests arbeitet:

1. Committe den gemeinsamen Dev-Workspace. Der Status sollte Synced sein, bevor jemand ein Branch out macht.
2. Mach für jede Änderung ein Branch out in einen neuen Workspace. Wähle die Items, drück Select related items.
3. Lies vor jedem Commit die Vergleichsansicht. Committe ganze Items.
4. Merge nur per Pull Request.
5. Prüf im gemeinsamen Workspace den Tab Updates, löse Konflikte mit geöffnetem Last sync vs. workspace und prüf dann den Git-Status. Hör erst auf, wenn er Synced ist.
6. Lösch den Branch Workspace, wenn der Pull Request gemergt ist.

Anpassen, wenn:

• du viele Notebooks oder Pipelines hast und File Level Commit willst. Pilotiere es an einem Item-Typ und ergänze eine Prüfung, dass sich das Item weiterhin aus Git importieren lässt.
• du das Anlegen von Branch Workspaces automatisieren willst. Die Workspace Relation API funktioniert, ist aber Preview, also behalte einen manuellen Ausweichweg.
• deine Kapazität geteilt und klein ist. Ein Branch Workspace verbraucht auch Kapazität, also halte die Auswahl knapp.

Probier es selbst aus

Die komplette Demo mit den Schritten, den Beobachtungen und den Belegen liegt in tech-demos/fabric-branch-workspaces. Sie läuft auf einer Trial-Kapazität mit synthetischen Daten, und die Zeiten darin sind Einzelläufe, keine Benchmarks.

Verwandte Notizen

• Fabric CI/CD: Wie begrenzt du den Blast Radius über Dev-Workspaces hinweg? (was ein Deployment anfasst, verglichen mit dem, was Git geändert hat)
• Fabric CI/CD: Die ganze Leiter mergen oder nur Fertiges per Cherry-Pick? (eine Änderung nach vorn bringen, wenn der Branch mehrere enthält)
• Variable Library: Wie schaltest du aktive Wertesätze von Dev auf Prod um? (wie sich Wertesätze über Stages hinweg verhalten, was zählt, sobald Branch Workspaces sie bearbeiten)
• Workspace-Benennung: Ist einmal umbenennen billiger, als Präfixe für immer zu übersetzen? (Branch Workspaces vermehren sich schnell, also benenne sie mit Absicht)