This post is a back-to-basics Git introduction for Microsoft Fabric enthusiasts. Because I am very aware a lot of Microsoft Fabric enthusiasts are from different backgrounds. Which means that Git may not be their focus area.
To manage expectations, this post is aimed at those with little or no experience of Git. However, those with experience can learn things in this post. Because it lays the foundation for various topics.
For instance, I add some details about how Git relates to working with Microsoft Fabric. However, I keep it to a minimum for this post. I keep most topics broad so that those working other areas can also understand Git better. Admittedly I share a few Microsoft Fabric resources to help others towards the end.
This is a primer to Git, not a full reference guide. Topics covered include:
- Git explanation
- Advantage of Git being centralized
- Working with Git repositories
- Committing a Git repository
- Pull requests
- Helpful resources
Along the way I share additional links.
Git explanation for Microsoft Fabric enthusiasts
Git is that it is a distributed version control system that allows you to track changes in a folder/directory. In other words, the version control goes wherever the folder goes. These folders/directories are known as Git repositories.
Below is a diagram to help visualize this.
These repositories are great when it comes to keeping track of code changes. Which is why they are so popular with developers. However, they can store a variety of items.
For example, you can store metadata about Microsoft Fabric items. You can even store other file types like PowerPoint files. My advice is to stick with text based files as much as possible for optimization and usability reasons.
To break down an explanation of a Git repository in its simplest form, it is essentially a folder with a hidden “.git” folder. Within that folder is a proprietary database format which manages all the changes in that folder.
This allows the version control to travel wherever the folder goes. Which means that if you delete this hidden folder the source control will go with it. My advice is to not delete this hidden folder unless you know what you are doing.
When you work with a Git repository you can checkout a new branch. Which is an isolated section of the repository that you can work in.
When you work with a branch in an application or online it looks like you are working with a separate copy of another branch. However, in reality the database is managing all the changes behind the scenes with pointers.
Advantage of Git being distributed
In the past, popular version control systems were centralized. Due to the fact that all the changes were stored in one central place, usually on a server or website. Making changes typically required a centrally managed check-in/check-out process. Which made version control very rigid.
Introducing a distributed model introduces more flexibility. Because the version store travels with the repository.
Which makes it easier to share Git repositories both privately and publicly online. The latter being very popular within the open-source community. Which you can see for yourself by searching GitHub or viewing the Fabric Essentials listings.
Working with Git repositories
Most popular locations to work with Git repositories are either locally or directly in an Application Lifecycle Management offering such as Azure DevOps or GitHub.
You need to install a Git related application locally to work with a Git repository. Either directly from git-scm.com or through an install of a related application. When working with Microsoft Fabric I recommend managing Git with an IDE that makes Git user-friendly to work with. Such as Visual Studio Code.
Getting started with a Git repository locally
Once a Git-related application is installed there are two options to start working with a repository locally.
First option is to initialize a folder on your local machine to make it a Git repository. In other words, create a repository yourself. Applications such as Visual Studio Code contain an easy option to do this. When you create a new repository this way you can link it to another copy of the repository elsewhere. Done by adding a remote.
Typically you add one repository location which you call origin. This tends to be the central location that is shared by others and is stored in a service like the ones mentioned at the start of this section. So that you can collaborate with others. Plus, work with the central location to perform CI/CD.
Second option is to make a clone/copy from an offering such as the ones mentioned previously. Easiest option is to get the URL of the repository from the service and then select the option to clone a repository in your local application.
Both options are very common with teams looking to perform CI/CD.
For example, when working with local repositories containing Power BI Desktop projects they will synchronize with a repository stored elsewhere. Which can the update a Microsoft Fabric workspace.
Committing a Git repository
When you are happy with your changes in a branch you can harden your changes by performing a commit. Which is basically a hard save of the branch you are working in.
When you work with Git through the command line you use the “git add” command to specify files you want to “stage” before doing a commit. However, when working like applications like Visual Studio Code that part is done for you. You just need to ensure that the relevant files have been saved in a particular branch.
Similar concept applies when working with Microsoft Fabric workspaces that are configured with Microsoft Fabric Git integration. Because you can select only the items you want committed before selecting commit. I covered Microsoft Fabric Git integration in detail in a previous post.
Pull requests
Pull requests are basically where you put a request in to merge the commits performed in one Git branch to another. For example, after performing commits in a feature branch you raise a pull request to merge the commits into a development branch.
Helpful resources
In reality, there are plenty of helpful resources for Git online. Here is a short burst of ones that apply to Git in general:
- Git cheat sheet
- Git reference
- GitHub Training kit (for multiple languages)
- Source Control in VS Code
For GitHub there is a large amount of documentation available. One good starting point is the about GitHub and Git document.
For Azure DevOps you can go through the Azure Repos documentation.
Here are some good resources for those looking for help when experiencing issues working with Git and Microsoft Fabric:
Final words
I decided to write this Git introduction for Microsoft Fabric enthusiasts after a couple of requests. So I hope it proves to be useful.
Because knowing the basics of Git can help you when it comes to setting up version control and resolving issues. You can also build on the knowledge to design your own CI/CD strategies.
1 thought on “Git introduction for Microsoft Fabric enthusiasts”