![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 10%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVK%3C/text%3E%3C/svg%3E)
The described behavior (workspace not reflecting branch changes, then starting to work again after re‑branching) is not documented in the provided context as a known, tracked Fabric Git Integration defect. The context only documents specific, scoped Git integration issues and limitations.
From the available information, only the following can be stated:
- Known Git integration issues in context
The documented Git/workspace issues are:
- Workspaces not appearing when branching out if the user lacks permissions.
- Branching out to a new workspace where Git integration is not enabled tenant‑wide, causing the new workspace not to be Git‑connected until Git integration is enabled in workspace settings.
- Connection failures when the selected Git folder:
- Does not exist, was deleted, or has case‑sensitivity differences.
- Contains only subdirectories and no Fabric item directories (no
item.config.jsonanditem.metadata.json).
- Source control icon not showing a change count, indicating a connection problem that can be resolved by disconnecting and reconnecting.
- Premium license requirements to connect to Git.
- Uncommitted changes status caused by folder structure differences between workspace and Git (for example, workspace has folders but the Git folder does not), which must be committed or handled via a checkout branch workflow.
- Best practices and preventive patterns from context
While the context does not list explicit “preventive measures” for the exact symptom, it does describe recommended patterns that help avoid Git/workspace state mismatches:
- Use separate workspaces per branch:
- Each workspace connects to a single branch and is a shared runtime environment. Recommended practice is to use separate workspaces per developer or per branch, via branched workspaces or client tools, to avoid conflicting changes and unclear sync states.
- See: development process using branched workspace and client tools.
- Handle folder and structure changes explicitly:
- Empty folders are not auto‑deleted and folder structure is retained up to 10 levels.
- If the workspace has folders and the connected Git folder does not (or vice versa), Fabric may show uncommitted changes that must be committed before updating the workspace. If direct commits to the connected branch are restricted, use the “Checkout Branch” flow:
- Checkout a new branch from the last synced state.
- Commit folder changes there.
- Merge via normal PR process.
- Use checkout‑branch conflict resolution when Git and workspace diverge:
- For conflicts or unclear differences, the recommended pattern is to:
- From Source control, check out a new branch using the last synced branch ID.
- Commit workspace changes into that new branch.
- Resolve conflicts and merge in Git.
- Switch the workspace back to the original branch.
- For conflicts or unclear differences, the recommended pattern is to:
- Ensure the Git folder is valid for connection:
- When connecting or reconnecting, verify that the target folder in Azure DevOps contains at least one valid Fabric item directory (with
item.config.jsonanditem.metadata.json) and is not only subdirectories.
- When connecting or reconnecting, verify that the target folder in Azure DevOps contains at least one valid Fabric item directory (with
- Use separate workspaces per branch:
- Backend sync delays or service limitations
The provided context does not document any general or current backend sync delays, throttling, or transient service limitations for Fabric Git Integration. The only explicit limitations called out are:
- Commit size limit of 150 MB for Fabric environments (custom libraries larger than this cannot be committed).
- Various unsupported CI/CD scenarios around warehouses with different collations (deployment pipelines, branching out, switching branches, merging across workspaces), which can cause metadata issues but are not described as causing items to disappear from the workspace.
- Practical guidance based on documented behavior
Based on the documented patterns, the following operational practices are supported by the context:
- When the workspace appears out of sync or items are missing:
- Check the Source control panel Git status for each item and the sync information bar (connected branch, last sync time, last commit link).
- If the Source control icon shows no number and the workspace appears disconnected, disconnect and reconnect the Git integration.
- If uncommitted changes appear without obvious edits, inspect for folder structure differences and either commit those changes or use the checkout‑branch workflow to normalize the state.
- When branching out or creating new workspaces:
- Ensure Git integration is enabled at the tenant level and for the workspace; otherwise, the new workspace will not be Git‑connected until Git integration is manually enabled in workspace settings.
- Confirm that the workspace to be branched out from is visible and that the user has permission to view it; otherwise, it will not appear in the branching‑out list.
- For persistent or transient issues not explained by the above:
- Use the checkout‑branch conflict‑resolution pattern to re‑establish a clean, known‑good state and then merge back to the main/Dev branch.
- When the workspace appears out of sync or items are missing:
Within the provided material, there is no explicit confirmation that the exact symptom described is a known, tracked Fabric Git Integration bug, nor any mention of current backend sync delays. The only supported guidance is to follow the documented Git integration patterns, ensure valid connections and folder structures, and use checkout‑branch workflows and separate workspaces per branch to minimize sync anomalies.
References: