Git integration and deployment pipelines in Fabric
Fabric is a team platform, so the exam expects you to know how work is versioned and promoted. Two tools cover this: Git integration for source control and deployment pipelines for release.
Git integration
A workspace connects to one branch of a Git repository (Azure DevOps or GitHub) and optionally a folder in it.
| Provider | What you supply |
|---|---|
| Azure DevOps | Organization, project, repository, branch, folder (same Microsoft Entra account) |
| GitHub | Personal access token (or connected account) and the repository URL, then branch |
Key behaviors:
- Items are stored as definition files (text), not data. Lakehouse data and table rows are never committed.
- You commit workspace changes to the branch and update the workspace to pull Git changes.
- Each developer can work in their own workspace tied to a feature branch, then merge by pull request.
- Not every item type is supported, so check before relying on Git for a new item.
Power BI projects
In Power BI Desktop, save as a Power BI project (PBIP) to get a folder with a report definition and a semantic model definition (TMDL or model.bim) as text files. This is the answer when a question wants readable files and easy merges.
In the project, .gitignore excludes cache.abf (cached data) and localSettings.json (user settings). Never commit data values.
Deployment pipelines
A deployment pipeline has up to 10 stages, normally Development, Test and Production. Each stage maps to a separate workspace.
- You deploy forward from one stage to the next. You can also deploy backward.
- Content is compared between stages so you can see what differs.
- Deployment rules change environment-specific values, such as the data source or a parameter, when content lands in the next stage.
- Folders are kept: if a lakehouse sits in a folder in the source, it lands in the same folder in the target.
- The workspace must be on a Fabric capacity (or Premium) license.
Permissions to remember: to deploy you need pipeline access plus at least Contributor on both source and target workspaces. Giving a developer only Viewer on Production blocks them from deploying there, which is the usual least-privilege answer.
Git or pipelines
They solve different problems and are often combined: Git tracks history and branching for development, pipelines move tested content between environments.
Exam traps
- Git stores item definitions, never lakehouse or warehouse data.
- A workspace connects to one branch at a time.
- PBIX is a single binary file, PBIT is a template with no data, PBIP is the text-based project format.
- Changing a data source per stage is a deployment rule, not a manual edit after deployment.
- Pipeline permission alone is not enough: you also need workspace access on both stages.
Practice questions
Choose an answer, then review the explanation to check your understanding.
1. You must link a Fabric workspace to the main branch of a GitHub repository. What do you provide?
Show answer
Answer: B.GitHub connections use a personal access token (or a connected account) plus the repository URL. You then pick the branch and folder.
2. A team wants report and semantic model definitions stored as individual text files in a folder tree, so changes can be reviewed in pull requests. Which Power BI Desktop format should they save in?
Show answer
Answer: C.A Power BI project (PBIP) saves the report and model as folders of text files, which suits source control.
3. Developers must deploy only to Development and Test, never to Production, with least privilege. What do you assign?
Show answer
Answer: A.Deploying needs write access on the source and target stages. Keeping developers as Viewer on Production stops them from deploying there.
4. Which file should you add to .gitignore so cached data values are not committed from a Power BI project?
Show answer
Answer: B.cache.abf holds the cached data. The definition files are what you want in the repository.