Git (version control)

What is Git?

Git is a version control system. It records changes to files over time so you can see what changed, who changed it, when it changed, and why. You can return to an older version, compare two versions, or let several people work on separate branches and merge their work later.

The familiar alternative is a folder full of files called Report_v2.xlsx, Report_final.xlsx, and Report_final_really_final.xlsx. Git moves the history behind the file instead of creating endless copies beside it.

Git is free and open source. Linus Torvalds created it in 2005 for Linux kernel development. It became the standard version control system for software teams and is now increasingly relevant for data and BI teams too.

The four ideas you need first

Repository
A repository, or repo, is the folder Git tracks, together with its full history. It contains the current files and the hidden Git history behind them.

Commit
A commit is a saved snapshot of a deliberate change. It records the content, author, timestamp, and message. Good commit messages explain the reason, not just the fact that something changed.

Branch
A branch is a parallel line of work. You create one to fix a report, test a model change, or build a feature without disturbing the main version.

Merge
A merge brings branch changes back together. Git combines the changes automatically where it can and asks for help when two people changed the same line.

With just these four concepts, a non-developer can understand most team workflows around Git.

Git is not a backup

A backup protects you against loss. Git protects you against confusion.

A backup says: here is a copy from last Tuesday. Git says: here are the exact changes made since last Tuesday, who made them, which issue or reason they belong to, and how to revert only that change if needed.

Git also enables collaboration. Two people starting from the same backup can overwrite each other. Two people working on branches can review and merge changes deliberately.

You still need backups for data, infrastructure, and disaster recovery. Git is for source files, definitions, code, configuration, models, scripts, and other text-friendly assets.

Why Git matters for data teams

For years, Git was awkward for BI teams because many reporting tools stored everything in large binary files. Git could tell that a file changed, but not what changed inside it.

That is changing. Power BI Project files, or PBIP, break a report and semantic model into folders and text-based definitions. Semantic models can use TMDL. Report definitions can be stored in PBIR. dbt models are SQL files. Notebooks, pipeline definitions, YAML files, and transformations are files too.

Once the work is represented as text, Git becomes useful:

• Review before release. A teammate can inspect changed measures, model definitions, SQL, or report metadata before it reaches production.

• Rollback. If a measure change breaks month-end reporting, you can return to the previous version.

• Collaboration. Two people can work on separate changes without the last person who saves winning.

• Deployment discipline. Git can feed a development workspace, automated checks, and a deployment pipeline.

• AI-assisted changes. When AI agents edit text-based report or model files, Git gives humans a reviewable diff.

The local Data Panda blog on Power BI version control makes the same point: PBIX is hard for Git because it is binary; PBIP makes the report and model diff-friendly.

Git, GitHub, and Azure DevOps

Git is the version control technology. GitHub and Azure DevOps are services that host Git repositories and add collaboration features.

Those features include pull requests, code review, permissions, issue links, automated checks, build pipelines, and deployment workflows. You can use Git without GitHub, but a team usually wants a shared remote repository somewhere.

An analogy: Git is the email protocol; GitHub or Azure DevOps is a hosted mailbox and collaboration environment around it.

Git in Microsoft Fabric and Power BI

Microsoft Fabric supports Git integration for workspace items, with Azure DevOps and GitHub support depending on the current feature set and item type. Power BI Project files can also be deployed to Fabric workspaces through Fabric Git integration, APIs, or Power BI Desktop publishing.

A healthy setup separates two jobs.

Version control remembers what the correct source version is and how it changed.

Deployment pipelines move approved content through development, test, and production environments.

Git is the memory. The deployment pipeline is the release mechanism.

What belongs in Git?

Good candidates:

• PBIP projects, TMDL, PBIR, and report definitions;

• dbt models and SQL transformations;

• notebooks and scripts;

• pipeline definitions and configuration;

• documentation, tests, and metadata.

Poor candidates:

• passwords, API keys, and connection strings;

• large datasets and exports;

• local cache files;

• binary files where you need line-by-line review.

Once a secret is committed, deleting it in a later commit is not enough because it remains in history. Use environment variables, secret stores, workspace connections, or deployment settings instead.

What to watch out for

The mental model takes practice
Git is not just save-as with extra steps. Teams need simple rules: one main branch, one branch per change, clear commit messages, and review before production.

Binary files reduce the value
Git can store binary files, but it cannot show meaningful diffs. Prefer project formats that break work into text.

Large data does not belong there
Store data in the lakehouse, warehouse, or object storage. Store the definition of how data is produced in Git.

Commit messages are documentation
Fix is not useful six months later. Correct margin measure to exclude returns is.

Review what gets generated
Power BI, Fabric, and tooling can generate many metadata files. Agree what is source, what is cache, and what should be ignored.