🏭🗒️Microsoft Fabric: Git Repository [Notes]

Disclaimer: This is work in progress intended to consolidate information from various sources for learning purposes. For the latest information please consult the documentation (see the links below)! 

Last updated: 4-Jul-2025

[Microsoft Fabric] Git Repository

• {def} set of features that enable developers to integrate their development processes, tools, and best practices straight into the Fabric platform [2]
• 
  
• {goal} the repo serves as single-source-of-truth
• {feature} backup and version control [2]
• {feature} revert to previous stages [2]
• {feature} collaborate with others or work alone using Git branches [2]
• {feature} source control 
• provides tools to manage Fabric items [2]
• supported for Azure DevOps and GitHub [3]
• {configuration} tenant switches 
• ⇐ must be enabled from the Admin portal 
• by the tenant admin, capacity admin, or workspace admin
• dependent on organization's settings [3]
• users can create Fabric items
• users can synchronize workspace items with their Git repositories
• create workspaces
• only if is needed to branch out to a new workspace [3]
• users can synchronize workspace items with GitHub repositories
• for GitHub users only [3]
• {concept} release process 
• begins once new updates complete a Pull Request process and merge into the team’s shared branch [3]
• {concept} branch
• {operation} switch branches
• the workspace syncs with the new branch and all items in the workspace are overridden [3]
• if there are different versions of the same item in each branch, the item is replaced [3]
• if an item is in the old branch, but not the new one, it gets deleted [3]
• one can't switch branches if there are any uncommitted changes in the workspace [3]
• {action} branch out to another workspace 
• creates a new workspace, or switches to an existing workspace based on the last commit to the current workspace, and then connects to the target workspace and branch [4]
• {permission} contributor and above
• {action} checkout new branch )
• creates a new branch based on the last synced commit in the workspace [4]
• changes the Git connection in the current workspace [4]
• doesn't change the workspace content [4]
• {permission} workspace admin
• {action} switch branch
• syncs the workspace with another new or existing branch and overrides all items in the workspace with the content of the selected branch [4]
• {permission} workspace admin
• {limitation} maximum length of branch name: 244 characters.
• {limitation} maximum length of full path for file names: 250 characters
• {limitation} maximum file size: 25 MB
• {operation} connect a workspace to a Git Repos 
• can be done only by a workspace admin [4]
• once connected, anyone with permissions can work in the workspace [4]
• synchronizes the content between the two (aka initial sync)
• {scenario} either of the two is empty while the other has content
• the content is copied from the nonempty location to the empty on [4]
• {scenario}both have content
• one must decide which direction the sync should go [4]
• overwrite the content from the destination [4]
• includes folder structures [4]
• workspace items in folders are exported to folders with the same name in the Git repo [4]
• items in Git folders are imported to folders with the same name in the workspace [4]
• if the workspace has folders and the connected Git folder doesn't yet have subfolders, they're considered to be different [4]
• leads to uncommitted changes status in the source control panel [4]
• one must to commit the changes to Git before updating the workspace [4]
• update first, the Git folder structure overwrites the workspace folder structure [4]
• {limitation} empty folders aren't copied to Git
• when creating or moving items to a folder, the folder is created in Git [4]
• {limitation} empty folders in Git are deleted automatically [4]
• {limitation} empty folders in the workspace aren't deleted automatically even if all items are moved to different folders [4]
• {limitation} folder structure is retained up to 10 levels deep [4]
• {limitation} the folder structure is maintained up to 10 levels deep
•  Git status
• synced 
• the item is the same in the workspace and Git branch [4]
•  conflict 
• the item was changed in both the workspace and Git branch [4]
•  unsupported item
•  uncommitted changes in the workspace
•  update required from Git [4]
•  item is identical in both places but needs to be updated to the last commit [4]
• source control panel
• shows the number of items that are different in the workspace and Git branch
• when changes are made, the number is updated
• when the workspace is synced with the Git branch, the Source control icon displays a 0
• commit and update panel 
• {section} changes 
• shows the number of items that were changed in the workspace and need to be committed to Git [4]
• changed workspace items are listed in the Changes section
• when there's more than one changed item, one can select which items to commit to the Git branch [4]
• if there were updates made to the Git branch, commits are disabled until you update your workspace [4]
• {section} updates 
• shows the number of items that were modified in the Git branch and need to be updated to the workspace [4]
• the Update command always updates the entire branch and syncs to the most recent commit [4]
• {limitation} one can’t select specific items to update [4]
• if changes were made in the workspace and in the Git branch on the same item, updates are disabled until the conflict is resolved [4]
• in each section, the changed items are listed with an icon indicating the status
•  new
•  modified
•  deleted
•  conflict
•  same-changes
• {concept} related workspace
• workspace with the same connection properties as the current branch [4]
• e.g.  the same organization, project, repository, and git folder [4] 

Previous Post <<||>> Next Post 

References:

[2] Microsoft Learn (2025) Fabric: What is Microsoft Fabric Git integration? [link] 

What is lifecycle management in Microsoft Fabric? [link]

[3] Microsoft Fabric Updates Blog (2025) Fabric: Introducing New Branching Capabilities in Fabric Git Integration [link] 

[4] Microsoft Learn (2025) Fabric: Basic concepts in Git integration [link]
[5]  [link]

Resources:
[R1] Microsoft Learn (2025) Fabric: 

Acronyms:

CI/CD - Continuous Integration and Continuous Deployment

🧮ERP: Implementations (Part XIV: A Never-Ending Story)

ERP Implementations Series

An ERP implementation is occasionally considered as a one-time endeavor after which an organization will live happily ever after. In an ideal world that would be true, though the work never stops – things that were carved out from the implementation, optimizations, new features, new regulations, new requirements, integration with other systems, etc. An implementation is thus just the beginning from what it comes and it's essential to get the foundation right – and that’s the purpose of the ERP implementation – provide a foundation on which something bigger and solid can be erected. 

No matter how well an ERP implementation is managed and executed, respectively how well people work towards the same goals, there’s always something forgotten or carved out from the initial project. Usually, the casual suspects are the integrations with other systems, though there can be also minor or even bigger features that are planned to be addressed later, if the implementation hasn’t consumed already all the financial resources available, as it's usually the case. Some of the topics can be addressed as Change Requests or consolidated on projects of their own. 

Even simple integrations can become complex when the processes are poorly designed, and that typically happens more often than people think. It’s not necessarily about the lack of skillset or about the technologies used, but about the degree to which the processes can work in a loosely coupled interconnected manner. Even unidirectional integrations can raise challenges, though everything increases in complexity when the flow of data is bidirectional. Moreover, the complexity increases with each system added to the overall architecture. 

Like a sculpture’s manual creation, processes in an ERP implementation form a skeleton that needs chiseling and smoothing until the form reaches the desired optimized shape. However, optimization is not a one-time attempt but a continuous work of exploring what is achievable, what works, what is optimal. Sometimes optimization is an exact science, while other times it’s about (scientifical) experimentation in which theory, ideas and investments are put to good use. However, experimentation tends to be expensive at least in terms of time and effort, and probably these are the main reasons why some organizations don’t even attempt that – or maybe it’s just laziness, pure indifference or self-preservation. In fact, why change something that already works?

Typically, software manufacturers make available new releases on a periodic basis as part of their planning for growth and of attracting more businesses. Each release that touches used functionality typically needs proper evaluation, testing and whatever organizations consider as important as part of the release management process. Ideally, everything should go smoothly though life never ceases to surprise and even a minor release can have an important impact when earlier critical functionality stopped working. Test automation and other practices can make an important difference for organizations, though these require additional effort and investments that usually pay off when done right. 

Regulations and other similar requirements must be addressed as they can involve penalties or other risks that are usually worth avoiding. Ideally such requirements should be supported by design, though even then a certain volume of work is involved. Moreover, the business context can change unexpectedly, and further requirements need to be considered eventually. 

The work on an ERP system and the infrastructure built around it is a never-ending story. Therefore, organizations must have not only the resources for the initial project, but also what comes after that. Of course, some work can be performed manually, some requirements can be delayed, some risks can be assumed, though the value of an ERP system increases with its extended usage, at least in theory. 

Previous Post <<||>> Next Post