Source control for flows

What it does

Dataverse Git integration connects an environment's solutions directly to an Azure DevOps Git repository from inside the Solutions area, so makers commit and pull without touching a CLI. The older route — pac solution clone or unpack into files, commit, and pack on build — still works and remains the approach when you need full control of the build.

Key facts

Git integration is intended for development environments only. Test and production are fed by builds and pipelines, not by syncing.
What goes into source control is the unmanaged solution. Managed solutions are built from source and deployed downstream, which is what keeps source control as the source of truth.
Solution objects are stored in a format designed to be human-readable, and objects are no longer duplicated per solution — multiple solutions in the same repository and folder share a single copy of each object.
Environment variables unpack into separate JSON value files, so you can hold a different values file per environment and have Solution Packager pack the right one at build time.
Committing an environment's customisations lets you rehydrate a development environment from source, which is what makes short-lived dev environments practical.
Code-first objects — plug-ins, PCF controls — should be built through a solution build process and imported, not deployed straight into the maker environment. Doing the latter puts both compiled binaries and source in the repository.
Git integration requires Azure DevOps Git specifically.

When to use / skip

Turn it on for any development environment where more than one person builds, or where you'd be genuinely stuck if the environment were deleted. The rehydration story alone justifies it on longer programmes. Skip it for a single maker building a handful of flows on a short engagement — the setup and the discipline cost more than they return, and pipelines will still move the solution safely. Be honest with yourself about whether anyone will actually review the diffs, because that's the benefit people buy it for and rarely realise.

Configuration decisions

Native Git integration versus CLI unpack in a build pipeline, which mostly comes down to whether pro developers or makers are driving.
Repository and branch layout, and whether one repository holds several solutions in a shared folder.
Whether code-first components are built into an unmanaged solution and imported, or deployed directly into the maker environment and committed as binaries — the first is the recommendation.
Which environments sync, and whether developer environments are treated as disposable.
What a pull request actually gates, given that reviewing flow definitions is not the same activity as reviewing code.

Gotchas

Flow definitions are JSON with generated action names and GUIDs. A cosmetic reorder in the designer can produce a diff that looks substantial and means nothing, and a meaningful logic change can look trivial. Reviewers learn to distrust the diff.
Merging two people's changes to the same flow is not a realistic operation. Treat flow files as owned by one person at a time and coordinate outside Git.
Deploying code-first objects straight into a maker environment and committing gives you two copies in the repository — the source and the built binary — which drift apart quietly.
Committing an unmanaged solution captures the environment's state, including anything a maker changed and forgot to mention. That's the point, but it means noisy commits.
Source control doesn't capture Dataverse data, connections, or anything outside the solution. A rehydrated environment is a shell.

Consultant notes

Set expectations about code review up front. Clients hear "source control" and picture line-by-line review of business logic; what they'll actually get is version history, traceability and recovery, which are worth having on their own terms.
The rehydration argument is the one that lands with infrastructure and finance — short-lived dev environments free capacity and reduce the number of permanent sandboxes on the bill.
Agree a rule that one flow has one editor at a time. It sounds primitive and it prevents the merge conflicts that have no good resolution.
If the client is on GitHub rather than Azure DevOps, native Git integration is off the table and you're building the CLI-based route. Check this before you promise anything.

Worth revisiting if Git integration gains support for repositories outside Azure DevOps.