This post covers my recommended versions of GitHub to use with Microsoft Fabric based on different scenarios. Because I want to raise awareness of which versions best suit different scenarios when working with Microsoft Fabric Git integration and implementing CI/CD.
For instance, once you have configured Fabric Git integration and want to operationalize fabric-cicd to work with Microsoft Fabric and GitHub Actions in an enterprise production environment.
I recently did a LinkedIn poll about which Git provider people use to configure Microsoft Fabric Git integration for their production workloads. I noticed that a number of folks stated they were using the GitHub Free or Pro versions for their production workloads.

This prompted me to write this post about recommended versions of GitHub. Although you can configure Microsoft Fabric Git integration to work with these plans, I do not necessarily recommend them for certain types of workloads.
GitHub versions
To clarify, there are multiple versions of GitHub which GitHub calls plans. Ranging from the very popular GitHub Free and Pro versions to GitHub Enterprise. GitHub currently lists five versions. However, technically there are six since there are both Cloud and Server versions of GitHub Enterprise.
To manage expectations, this post covers these GitHub plans only. It does not GitHub Copilot plans at all, or the updated GitHub Copilot plans and pricing. You can find out more about the move to usage-based billing in the article published by GitHub.
Recommendations GitHub versions based on various Fabric and GitHub scenarios
I broke this post down into different scenarios to make sure nothing was taken out of context, as GitHub Free and Pro may be the better choice for certain scenarios. Along the way I share plenty of links.
To manage expectations I cover key points from a GitHub perspective. In order to perform some of the scenarios you will still need the relevant permissions applied in Microsoft Fabric. For example, service principal accounts added in workspace and tenant settings where required.
Learning and experimentation
As long as only with development samples the GitHub Free or Pro is fine to wok with. Doing this at the start of your journey with either of these versions is great. Because it provides a lot of flexibility and allows you to test what is possible without waiting for things like approvals.
Another reason these two plans are ideal is that there is no sensitive information or data sovereignty required. Apart from maybe GitHub secrets that you store whilst testing CI/CD.
To clarify, when I say data sovereignty in the context of GitHub, I mean where GitHub stores your repositories. Only certain GitHub plans allow you to choose where GitHub stores your repositories. Which I cover later in this post.
Personal Fabric projects and demos
For personal projects and demos the GitHub Free and Pro plans can also be ideal. Especially if you are the only developer involved in creating a project or showing a demo.
Because you can be flexible with what you need in order for your projects and demos to work. At least at the GitHub end. I showed many demos over the years with these two different versions.
To manage expectations, if looking to do this in a Microsoft Fabric tenant the relevant permissions will still need to be applied there.
Public GitHub and Fabric community projects
Again the GitHub Free and Pro plans can be suitable for this scenario. Depending on the scale of your project. In fact, I share my public Git repositories with a GitHub Pro account.

Because you develop your Git repositories yourself and allow others can raise issues within them. If others are involved, you can add them as collaborators to your repositories as well.
However, if you ever need to scale out to with a large number of contributors, perform excessive tests and share multiple repositories the GitHub I recommend looking to work with GitHub Free for organizations instead.
GitHub Free for organizations is also good for when you need to share multiple Git repositories when delivering a workshop. Even more so when collaborating on a workshop with somebody else and you want a central place for all your demos.
For more excessive requirements like more additional minutes for GitHub Actions per month and multiple pull request reviewers consider GitHub Team instead.
Professional individual Fabric development
GitHub Free is fine for experimentation and creating certain community projects to share. However, if you are an individual professional developer working on private Fabric projects, GitHub Pro starts to make more sense because you gain additional controls around private repositories.
For example, with GitHub Pro you can implement protected branches, and you get an additional GitHub Actions allowance.
To clarify, production does not automatically mean you need to implement GitHub Enterprise. For an individual working on a production Fabric workload, GitHub Pro can be perfectly reasonable.
The plan you choose should be based on your requirements and your company’s policies, rather than simply whether the workload is classified as production. Once you require multiple developers or more advanced or organizational security requirements, that is when I recommend looking at either GitHub Team or GitHub Enterprise.
Small/medium Fabric development team
Once multiple developers are contributing to a Fabric solution in the workplace, I recommend GitHub Team at the very least. While GitHub Free and Pro allow collaboration, GitHub Team provides additional organization and collaboration capabilities that become increasingly important as the development team grows.
This includes the options to include multiple pull request reviewers . Plus, the ability to purchase GitHub Code Security and GitHub Secret Protection. Providing additional governance and security controls for collaborative development.
However, depending on your requirements you might want to consider GitHub Enterprise. Especially if you require additional security, compliance and deployment controls.
Enterprise Fabric platform environments
For enterprise-grade Microsoft Fabric production environments I recommend GitHub Enterprise Cloud. I personally think this version is the first plan that provides the level of governance and control I would expect from Azure DevOps. Which is the other provider that supports Microsoft Fabric Git integration.
Note that I say GitHub Enterprise Cloud. There is a GitHub Enterprise Server version which you can install on your own machines. Which provides a different level of control over where GitHub is hosted and how it is managed. However, it is not currently supported by Microsoft Fabric Git integration.
As the name suggests, this is an enterprise-grade version of GitHub. With plenty of features to address a high level of governance. Including additional security, compliance and deployment controls when compared to other GitHub Plans.
However, one of the main reasons a lot of you will require GitHub Enterprise when working with enterprise Fabric platforms is data residency.
In the past, when you created a Git repository in GitHub you had no control over where it was stored. GitHub Enterprise Cloud now offers you the option to store your code and data in one of the following regions:
- EU (includes Azure regions in EFTA countries, currently Norway and Switzerland)
- Australia
- US
- Japan
However, not all GitHub data is necessarily stored within that region, so it is important to review exactly which data GitHub stores inside and outside the selected region. GitHub documents what data is stored in your region and also which data is stored outside of your region.
Personally, I think the governance and data residency requirements are both very strong cases for GitHub Enterprise in an enterprise-grade Microsoft Fabric production environment.
Summary about recommended versions of GitHub
I hope my recommended versions of GitHub to use with Microsoft Fabric based on different scenarios have been insightful. I wanted to highlight that GitHub Free and Pro are good for certain scenarios.
Another key point is that a production Fabric workload does not automatically mean GitHub Enterprise. However, depending on your requirements I recommend considering either GitHub Team or GitHub Enterprise.
Feel free to share your thoughts about these scenarios in the comments.
Great post.
do you have an opinion on git vs ADO.
Do you mean GitHub vs Azure DevOps, if so then yes I do. However which ne you choose mostly depends on if the environment is using one already.