Add Git Integration Support for Tables, Views, Functions, and Stored Procedures in Lakehouses
I’m aware that Lakehouse Git integration in Microsoft Fabric is currently in preview. However, I believe some critical support is missing that would significantly enhance the usability and maturity of this feature.
At the moment, Git integration does not support versioning or tracking of critical Lakehouse objects such as:
- Tables
- Views
- User-defined functions
- Stored procedures
These objects are essential components of any data platform, and not being able to track their definitions in source control limits our ability to:
- Perform proper code reviews
- Roll back changes
- Maintain consistent environments across workspaces
- Collaborate effectively in larger teams
- Follow DevSecOps best practices
Suggestion:
Please extend Git integration in Fabric Lakehouses to include full support for these objects. For example, warehouse git integration supports all of those objects.
This enhancement would greatly improve DevOps practices in Fabric and align with modern data engineering workflows.
1 Comment
- murat-to
Advocate II
I strongly agree with this idea.
Git integration for Lakehouse objects such as tables, views, functions, and stored procedures is essential for proper DevOps workflows, change management, and governance.
I would also like to add an important related point:
in order for Git integration to be truly effective, we need an official way to retrieve the canonical table definition (DDL) itself.
At the moment, DESCRIBE EXTENDED in Spark SQL can be used only as a workaround to inspect metadata, but it is not a reproducible or authoritative DDL.
This makes it difficult to:
- manage schemas as code (Schema as Code)
- review schema changes via pull requests
- track structural changes across environments
- ensure reproducibility and auditability
In traditional RDBMS platforms, features like SHOW CREATE TABLE are first-class capabilities and form the foundation of schema governance and CI/CD.
Git integration and DDL exposure should be considered complementary capabilities.
Having both would significantly improve Lakehouse schema management in enterprise environments.
Thank you for raising this important idea.
Recent ideas
Allow Excluding Specific Tables or Columns from Automatic Relationship Detection
Power BI automatically detects and creates relationships between tables when data is loaded. While this is useful, there are scenarios where certain tables or columns are intentionally designed to re...MohamedFowzan11 minute agoSuper UserNew0Views0likes0CommentsHave a DIRECT way to reach the *Transform Data Button* from any menu.
Hi. Currently (2026), in PowerBI you have to go click the HOME menu, than click the Transform Data button, each time you want to reach the Query editor menu. Please either create a dedicated button /...MOFabric1 hour agoRegular VisitorNew4Views0likes0CommentsShow clickable links to dependent objects, aka a usable lineage
I have say 12 reports connected to a semantic model which I have just changed so I need to check if anything has broken. This use to be easy, just click the semantic model to see dependents but this ...skiwii3 hours agoAdvocate INew5Views0likes0CommentsexecuteDaxQueries-like API call with effectiveUserName on SSO-enabled model with Service Principal
Please provide a way for a service principal to execute DAX - with an effective user name - against an SSO-enabled directlake semantic model and get per-user results that respect lakehouse OneLake Se...sean_cochran4 hours agoResolver INew4Views0likes0Comments