Version Control: Git in Fabric
Connect your workspace to Git, track changes, resolve conflicts, and implement database projects for source-controlled analytics.
Why version control in Fabric?
Think of Google Docs version history — but for your entire data platform.
Imagine you change a pipeline on Friday afternoon, and Monday morning everything is broken. Without version control, you’re guessing what changed. With it, you see exactly what changed, who changed it, and you can roll back in seconds.
Git integration connects your Fabric workspace to a Git repository (Azure DevOps or GitHub). Every lakehouse definition, notebook, pipeline, and report gets tracked as code. You branch, merge, review, and deploy — just like software developers do.
How Git integration works
The flow is straightforward but has important nuances:
- Connect — Link a workspace to a Git repo branch (e.g.,
main,dev) - Commit — Push workspace changes to the repo (serialised as definition files)
- Update — Pull repo changes into the workspace (e.g., a teammate merged a PR)
- Branch — Work on a feature branch, then merge via pull request
What gets version-controlled
| Item Type | What’s Stored in Git | What’s NOT Stored |
|---|---|---|
| Notebook | Python/Scala/R/SQL code, metadata | Spark session state, output cells |
| Pipeline | JSON pipeline definition (activities, parameters, triggers) | Run history, logs |
| Lakehouse | Metadata definition | Actual data files and Delta tables |
| Warehouse | Schema via database projects (SQL scripts) | Data, query results |
| Dataflow Gen2 | Mashup (Power Query M) definition | Refresh history |
| Environment | Library lists, Spark configuration | Installed library binaries |
| Report/Semantic model | Definition files | Cached data, refresh state |
Scenario: Ibrahim's branching strategy
Ibrahim sets up a branching strategy for Nexus Financial’s Fabric workspaces:
mainbranch → connected to the Production workspace (locked — only receives merges via PR)devbranch → connected to the Development workspace (engineers work here daily)- Feature branches → individual engineers create feature branches for major changes, then open PRs to merge into
dev
Each engineer connects their personal dev workspace to their feature branch. When they commit, changes flow to the branch. When the PR is approved, changes merge into dev, and the dev workspace updates.
Conflict resolution
When two engineers change the same item, Git integration detects a conflict. Fabric does not do line-level merge for most item types — it’s an all-or-nothing per item.
| Conflict Type | Resolution |
|---|---|
| Same item changed in workspace and repo | You choose: keep workspace version or accept repo version |
| Different items changed | No conflict — both changes apply |
| Item deleted in one location | You choose: restore or accept deletion |
Exam tip: Git vs deployment pipelines
The exam distinguishes between Git integration (version control — tracking changes, branching, merging) and deployment pipelines (promoting content between environments — dev → test → prod). They complement each other:
- Git answers: “What changed? Who changed it? Can we roll back?”
- Deployment pipelines answer: “Is this tested? Can we push it to production?”
Don’t confuse them. A workspace can use both simultaneously.
Database projects
Database projects bring traditional SQL Server database development patterns to Fabric warehouses. They let you define your warehouse schema as SQL scripts in Git, then deploy changes as a unit.
Why database projects matter
Without database projects, warehouse schema changes happen directly in the Fabric UI — one ALTER TABLE at a time, with no review process and no rollback.
With database projects:
- Schema is defined as
.sqlfiles in a Git repo - Changes go through pull request review
- Deployments are idempotent — the tool compares desired state vs current state and generates the diff
- Schema can be validated before deployment
What’s in a database project
| Component | File Type | Example |
|---|---|---|
| Tables | .sql | CREATE TABLE dbo.FactSales (...) |
| Views | .sql | CREATE VIEW dbo.vw_MonthlySales AS ... |
| Stored procedures | .sql | CREATE PROCEDURE dbo.usp_LoadDimCustomer ... |
| Functions | .sql | CREATE FUNCTION dbo.fn_FiscalYear ... |
| Project file | .sqlproj | Build configuration, target platform |
Scenario: Carlos migrates to database projects
Carlos Reyes is an ETL Developer at Precision Manufacturing. His warehouse has 47 tables, 12 stored procedures, and 8 views — all created manually through the Fabric UI over six months.
When a junior engineer accidentally drops a production view, Carlos decides to adopt database projects. He exports the current schema, organises it into a .sqlproj structure in Git, and sets up a rule: no direct schema changes in the UI. All changes go through PRs.
The next time someone needs to add a column, they modify the .sql file, open a PR, get it reviewed, and the deployment tool applies only the diff.
Ibrahim connects the Production workspace to the `main` branch. An engineer accidentally commits a broken notebook directly to `main` from a different workspace. What is the most reliable way to prevent this?
Carlos wants to add a new column to a production warehouse table. His team uses database projects. What is the correct workflow?
Which of the following Fabric items are NOT supported by Git integration?
🎬 Video coming soon
Next up: Deployment Pipelines: Dev to Production — promote your validated changes through environments safely.