Forum Discussion
Solved
SQL Database - Source Control
Hi I can't find information to confirm the following: (I'll simplify the scenario) I have a workspace thats connected to an Azure DevOps Repo. It contains a SQL Database with two tables - Tabl...
Hello going_grey
This is expected behaviour. Fabric Git integration only manages artefact definitions and does not reconcile or enforce the physical schema inside a SQL Database or Warehouse. Dropping a table in a branched workspace is a runtime DDL change and isn’t tracked or replayed when you merge and update the main workspace. As a result, existing tables like Table B will remain unless they’re explicitly dropped in that workspace (or via a deployment script). Git sync today is additive and non‑destructive by design.Fabric Git integration is Source control for the shell of the database, not its contents.Dropping a table is comparable to:
- Deleting rows inside a lakehouse
- Running TRUNCATE TABLE
- Changing data, not definitions
Those actions are outside Git reconciliation.
Hello going_grey
This is expected behaviour. Fabric Git integration only manages artefact definitions and does not reconcile or enforce the physical schema inside a SQL Database or Warehouse. Dropping a table in a branched workspace is a runtime DDL change and isn’t tracked or replayed when you merge and update the main workspace. As a result, existing tables like Table B will remain unless they’re explicitly dropped in that workspace (or via a deployment script). Git sync today is additive and non‑destructive by design.
Fabric Git integration is Source control for the shell of the database, not its contents.
Dropping a table is comparable to:
- Deleting rows inside a lakehouse
- Running TRUNCATE TABLE
- Changing data, not definitions
Those actions are outside Git reconciliation.