Microsoft Fabric Git integration jargon guide for Fabricators

Reading Time: 9 minutes

Welcome to my Microsoft Fabric Git integration jargon guide for Fabricators. Which I decided to create for a variety of reasons.

Including the fact that I used a fair amount of jargon in my last post. Where I covered working with Microsoft Fabric Git integration and multiple workspaces.

Another reason is because I appreciate that a lot of people who work with data do not know what certain terms are.

Which is why I often say or write the phrase “to help with some jargon”. Like I did in my previous post about my initial Microsoft Fabric Git integration tests.

Luckily, I have a fair bit of experience with both the Microsoft Data Platform and Development Technologies such as Azure DevOps. So, I am in a good position to help.

In addition to explaining some jargon, I also provide plenty of links in this post to help. Below is an overview of the sections covered in this post:

• Two pieces of jargon in the title
• Azure DevOps jargon guide for Fabricators
• Git
• Git repository
• Branches
• Power BI Desktop projects
• Pull request
• Sync and Synced
• Source control, changes and updates

One key point to note is that Microsoft Fabric is now generally available. You can read more about this in detail in the official post by Ryan Majidimehr.

Two pieces of jargon in the title

I do realize that that thanks to the title I must explain two pieces of jargon before I go any further.

First of all, Microsoft Fabric Git integration allows you to synchronize supported items in a Microsoft Fabric workspace with a Git repository stored in Azure DevOps.

It does this by storing the details about the items as metadata. Which you can think of along the lines of code.

At this moment in time, the supported items for Microsoft Fabric Git integration are Lakehouses, notebooks, reports, paginated reports and semantic models(datasets).

Doing this opens up some interesting scenarios. Like working with multiple workspaces like I showed in my previous post.

Secondly, Fabricators is a nickname that has been given to people who are interested in Microsoft Fabric.

Now that is out of the way I will carry on with the rest of the guide.

Azure DevOps jargon guide for Fabricators

Since Azure DevOps is critical for Microsoft Fabric I thought I better cover it first. It is a service that allows you to manage your Application Lifecycle Management. From creating your initial work item all the way through to deployment.

In reality, there are two types of Azure DevOps. Azure DevOps Services is the cloud version and Azure DevOps Server is the version you can install on your own servers. Microsoft Fabric Git integration only supports the cloud version at this moment in time.

Azure DevOps comes with its own hierarchy:

• Azure DevOps account which contains one or more organizations.
• An organization can contain one or more projects.
• Each project contains various services which allows you to do various tasks.

Each new Azure DevOps project comes with a default set of services that you can work with. As you can see below.

For now, the main thing you need to know is that Git repositories are saved in the Azure Repos service. Which allows you to work with a visual representation the Git repository stored there. As you can see in the below example.

If you are working in a workspace that already has Microsoft Fabric Git integration configured there is a quick way you can access the repository it uses in Azure Repos.

You can do this by opening up source control in your workspace, clicking on the ellipsis (the three dots) and selecting ‘View ADO repository.’

Git

Git is what is a known as a distributed version control system. In short, it is a way to store code in one or more locations where the changes can be tracked.

To help with some other jargon here, sometimes other terms are used for Git sometimes instead of version control. Including source control, which also happens to be the name of the option you click on in a workspace to manage changes to Microsoft Fabric Git integration.

A typical way to work with Git is to have one copy of the repository stored in a central location, such as Azure Repos, and one or more clones (copies) on local machines. Afterwards, people who are working with their local copies tend to synchronize it with the central location.

In reality, you can clone this repository elsewhere though by creating other remotes. However, most common pattern is just one remote which tends be called origin.

Most important thing to remember is that Git does not come installed on your operating system by default. Typically, it either it gets installed along with an application or downloaded directly from git-scm.com.

Git repository

A Git repository is basically a folder/directory where you store the files and folders that you want to work with. You can think of it as a folder/directory being converted to work with Git.

Microsoft Fabric Git integration works with Git repositories stored in Azure Repos. Which is the service in Azure DevOps that stores Git repositories.

You tend to create a repository in Azure Repos as below. To get it to work with Microsoft Fabric Git integration straight away you would select to add a README file so that the Git project is initialized.

Doing this is ideal if you have Microsoft Fabric items in your workspace that you already want to synchronize.

To make a folder on your local computer a Git repository you need to initialize it. Typically, you tend to do this either by using the git-init command directly or through an application. Like the Visual Studio Code example I showed in my previous post.

When you initialize a folder a hidden .git directory subfolder gets created in the root of the repository. Which manages your version control. Luckily, a lot of applications and services hide this folder to make working with Git easier.

Once you make your folder a Git repository you can do an initial commit. Which will enter any existing files or folders into version control. A commit basically hardens any changed since your last commit to the Git repository.

Just like when with initialize, you typically you tend to do this either by using the git-commit command directly or through an application. Like in the below example.

Branches

When you start looking to use Microsoft Fabric Git integration at scale you are probably going to be working with both branches and pull requests.

Branches are an interesting concept in Git. They allow you to work with your code in a new area within the same Git repository. Which looks and feels like an entirely new copy of your work.

Typically, you make changes in one branch and then merge those changes into another. These should not be confused with deployment environments. Where you deploy to various environments to perform various levels of testing before deploying to a production environment.

In reality, it does not make a full copy of your work in a new branch. Instead branches and changes are managed by Git. Those who are curious can read more in the Branches in a Nutshell document.

Anyway, there are a number of different ways you can manage branches. For example, locally you can manage them either through command line or directly in applications.

You can also create new branches in both Azure DevOps and Microsoft Fabric as you can see below.

One popular way to work with branches is to create what is knows as a feature branch. Which is a branch you work with short-term for a specific feature. Once finished you apply your changes back to the branch you were working on or another branch.

In reality, this all depends on your branching model. Branching models describe the different ways you work with branches. For example, you can work with two branches like in GitHub Flow or do you merge across many branches like in Git Flow.

One way you can do this is through a pull request which I cover later in this post.

Power BI Desktop projects

Power BI Desktop projects, also known as Power BI projects, is basically where you store elements of your Power BI reports as metadata (code). It breaks down all the various elements into different file types as you can see in the below example.

You can create these projects right now if you have a recent version of Power BI Desktop installed.

Working with these projects introduces some interesting possibilities. Including the fact that you can use these projects with Microsoft Fabric Git integration. Like I showed in my previous post about initial Git integration tests.

Just to make it clear by default only the local copy of this project contains data. If you synchronize this project elsewhere it does not transfer the data that you have cached locally.

Due to the fact that the ‘cache.abf’ file you work with locally is stored in a special type of file called ‘.gitignore‘. Which means that file is excluded by Git.

You can find out more about the structure of these projects along with the different files in the Power BI Desktop projects documentation.

TMDL

You can also use the new TMDL file format to define the schema of objects inside of your semantic models instead of the ‘model.bim’ file.

TMDL stands for Tabular Model Definition Language and is considered to be a more human-friendly format.

It does this by storing various ‘.tmdl’ files inside a ‘definition’ folder. As you can see below.

Various applications support this new file format. Including Power BI Desktop and Tabular Editor.

Pull request

Pull requests are basically where you put a request in to merge the contents of one Git branch to another.

One of the best descriptions I have heard for Pull Requests is from Marcel De Vries (t). He said that when you create a Pull Request you are starting a conversation.

If you look at an example form from my previous post, you can see what he means. Because you are invited to put in relevant details and decide who should review the Pull Request.

Once you have filled out the details, others can review the request and decide whether or not to approve and complete it to merge the updates.

Source control, changes and updates

Once you have configured Microsoft Fabric Git integration a source control button appears in your workspace. Which is your entry point to all things relating to source control. Including some tips that I mentioned earlier in this post.

You get two main tabs in this section. Changes show the changes you made in Microsoft Fabric itself and updates that show pending updates due to in the Git repository.

Sync and Synced

I thought I better cover these two together. To make it easier to explain the differences.

Sync (aka Synchronize changes) refers to a very useful feature in Visual Studio Code which allows you to easily synchronize your local clone(copy) of your Git repository with one elsewhere. For example, one in Azure Repos.

It basically saves you having to think about whether you need to pull or push changes.

In terms of Microsoft Fabric Git integration, synced is the term used when an item in Microsoft Fabric is synchronized with a repository in Azure Repos.

For those wondering, unsynced commits are where there is an item that has been updated in Fabric but has yet to be committed the Git repository in Azure Repos.

Final words about Microsoft Fabric Git integration jargon guide for Fabricators

I hope this Microsoft Fabric Git integration jargon guide helps some of you Fabricators out there understand some of the jargon better.

In reality, I could go deeper into other aspects of the jargon. For example, pull and push. However, I think that those pieces of jargon do not fully apply to the majority of those working with Microsoft Fabric Git integration.

Of course, if you have any comments or queries about this post feel free to reach out to me.